Информационные системы за время своего существования претерпели огромные изменения: от программ, способных выполнять только простейшие логические и арифметические операции, до сложных систем управления предприятиями.

В развитии программного обеспечения всегда можно было выделить два основных направления:

- выполнение вычислений;

- накопление и обработка информации.

Первоначально компьютеры предназначались главным образом для выполнения сложных математических расчетов (в первую очередь для расчетов, связанных с созданием ядерного оружия и ракетной техники), но в настоящее время доминирующим является второе направление. Такое перераспределение основных функций, выполняемых вычислительной техникой, вполне понятно – гражданский бизнес гораздо более распространен, чем военные и научные вычисления, а снижение стоимости компьютеров сделало их доступными для совсем небольших предприятий и даже частных лиц.

Сегодня управление предприятием без компьютера просто немыслимо. Компьютеры давно и прочно вошли в такие области управления, как бухгалтерский учет, управление складом, ассортиментом и закупками. Однако современный бизнес требует гораздо более широкого применения информационных технологий в управлении предприятием. Жизнеспособность и развитие информационных технологий объясняется тем, что современный бизнес крайне чувствителен к ошибкам в управлении. Интуиции, личного опыта руководителя и размеров капитала уже мало для того, чтобы быть первыми. Для принятия любого грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности, будь то торговля, производство или предоставление каких-либо услуг. Поэтому современный подход к управлению предполагает вложение средств в информационные технологии. И чем крупнее предприятие, тем серьезнее должны быть подобные вложения. Они являются жизненной необходимостью, ведь в жесткой конкурентной борьбе одержать победу сможет лишь тот, кто лучше оснащен и наиболее эффективно организован.

Современные информационные технологии предоставляют широкий набор способов реализации автоматизированных систем обработки информации и управления (АСОИУ), выбор осуществляется на основе требований со стороны предполагаемых пользователей, которые, как правило, могут изменяться в процессе разработки. Процесс проектирования системы – это процесс принятия проектных решений, направленных на получение версии системы, удовлетворяющей требованиям заказчика.

1. ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Индустрия разработки автоматизированных информационных систем управления родилась в 50-х – 60-х годах прошлого столетия и к концу века приобрела вполне законченные формы.

Под информационной системой обычно понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации. Подавляющее большинство информационных систем работает в режиме диалога с пользователем [шутки:12].

Под автоматизированной информационной системой промышленного предприятия будем понимать комплекс аппаратно-программных средств реализующих мультикомпонентную информационную систему, обеспечивающую современное управление процессами принятия решений, проектирования, производства и сбыта в режиме реального времени при транзакционной обработке данных.

В наиболее общем случае типовые программные компоненты, входящие в состав информационной системы, включают:

- диалоговый ввод-вывод;

- логику диалога;

- прикладную логику обработки данных;

- логику управления данными;

- операции манипулирования файлами и (или) базами данных.

Корпоративной информационной системой (КИС) мы будем называть совокупность специализированного программного обеспечения и вычислительной аппаратной платформы, на которой установлено и настроено программное обеспечение.

Под проектом будем понимать проектно-конструкторскую и технологическую документацию, в которой представлено описание проектных решений по созданию и эксплуатации системы в конкретной программно-технической среде.

Под проектированием системы понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в проект АСОИУ. С этой точки зрения проектирование АСОИУ сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла системы: предпроектного анализа требований, технического и рабочего проектирования, внедрения и эксплуатации АСОИУ.

Осуществление проектирования системы предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабу и особенностям разрабатываемого проекта.

Технология проектирования системы – это совокупность методологии и средств проектирования системы, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта системы).

В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Технологический процесс проектирования системы в целом делится на совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий, каждое из которых может иметь свой предмет.

Проектирование системы – трудоемкий, длительный и динамический процесс.

1.1. Факторы, влияющие на развитие информационных систем

В последнее время все больше руководителей начинают отчетливо осознавать важность построения на предприятии корпоративной информационной системы как необходимого инструментария для успешного управления бизнесом в современных условиях.

Можно выделить три наиболее важных фактора, существенно влияющих на развитие корпоративных информационных систем:

- развитие методик управления предприятием;

- развитие общих возможностей и производительности компьютерных систем;

- развитие подходов к технической и программной реализации элементов информационной системы.

Рассмотрим эти факторы более подробно.

Развитие методик управления предприятием. Теория управления предприятием представляет собой довольно обширный предмет для изучения и совершенствования. Это обусловлено широким спектром постоянных изменений ситуации на мировом рынке. Все время растущий уровень конкуренции вынуждает руководителей компаний искать новые методы сохранения своего присутствия на рынке и поддержания рентабельности своей деятельности. Такими методами могут быть диверсификация, децентрализация, управление качеством и многое другое. Современная информационная система должна отвечать всем нововведениям в теории и практике менеджмента. Несомненно, это самый главный фактор, так как построение продвинутой в техническом отношении системы, которая не отвечает требованиям по функциональности, не имеет смысла.

Развитие общих возможностей и производительности компьютерных систем. Прогресс в области наращивания мощности и производительности компьютерных систем, развитие сетевых технологий и систем передачи данных, широкие возможности интеграции компьютерной техники с самым разнообразным оборудованием позволяют постоянно наращивать производительность информационных систем и их функциональность.

Развитие подходов к технической и программной реализации элементов информационных систем. Параллельно с развитием аппаратной части информационных систем на протяжении последних лет происходит постоянный поиск новых, более удобных и универсальных методов программно-технологической реализации информационных систем.

Можно выделить три наиболее существенных новшества, оказавших колоссальное влияние на развитие информационных систем в последние годы:

- новый подход к программированию: с начала 90-х годов объектно-ориентированное программирование фактически вытеснило модульное; до настоящего времени непрерывно совершенствуются методы построения объектных моделей. Благодаря внедрению объектно-ориентированных технологий программирования существенно сокращаются сроки разработки сложных информационных систем, упрощаются их поддержка и развитие;

- благодаря развитию сетевых технологий локальные информационные системы повсеместно вытесняются клиент-серверными и многоуровневыми реализациями;

- развитие сети Интернет дало большие возможности работы с удаленными подразделениями, открыло широкие перспективы электронной коммерции, обслуживания покупателей через Интернет и многое другое. Более того, определенные преимущества дает использование Интернет-технологий в интрасетях предприятия (так называемые интранет-технологии).

Основные составляющие корпоративных информационных систем. В составе корпоративных информационных систем можно выделить две относительно независимые составляющие:

- компьютерную инфраструктуру организации, представляющую собой совокупность сетевой, телекоммуникационной, программной, информационной и организационной инфраструктур. Данная составляющая обычно называется корпоративной сетью;

- взаимосвязанные функциональные подсистемы, обеспечивающие решение задач организации и достижение ее целей.

Первая составляющая отражает системно-техническую, структурную сторону любой информационной системы. По сути, это основа для интеграции функциональных подсистем, полностью определяющая свойства информационной системы, определяющая ее успешную эксплуатацию. Требования к компьютерной инфраструктуре едины и стандартизованы, а методы ее построения хорошо известны и многократно проверены на практике.

Вторая составляющая корпоративной информационной системы полностью относится к прикладной области и сильно зависит от специфики задач и целей предприятия. Данная составляющая полностью базируется на компьютерной инфраструктуре предприятия и определяет прикладную функциональность информационной системы. Требования к функциональным подсистемам сложны и зачастую противоречивы, так как выдвигаются специалистами из различных прикладных областей. Однако, в конечном счете, именно эта составляющая более важна для функционирования организации, так как для нее, собственно, и строится компьютерная инфраструктура.

Соотношение между составляющими информационной системы. Взаимосвязи между двумя указанными составляющими информационной системы достаточно сложны. С одной стороны, эти две составляющие в определенном смысле независимы. Например, организация сети и протоколы, используемые для обмена данными между компьютерами, абсолютно не зависят от того, какие методы и программы планируется использовать на предприятии для организации бухгалтерского учета.

С другой стороны, указанные составляющие в определенном смысле все же зависят друг от друга. Функциональные подсистемы в принципе не могут существовать без компьютерной инфраструктуры. В то же время компьютерная инфраструктура сама по себе достаточно ограничена, поскольку не обладает необходимой функциональностью. Невозможно эксплуатировать распределенную информационную систему при отсутствии сетевой инфраструктуры. Хотя, имея развитую инфраструктуру, можно предоставить сотрудникам организации ряд полезных общесистемных служб (например, электронную почту и доступ в Интернет), упрощающих работу и делающих ее более эффективной (в частности, за счет использования более развитых средств связи).

Таким образом, разработку информационной системы целесообразно начинать с построения компьютерной инфраструктуры (корпоративной сети) как наиболее важной составляющей, опирающейся на апробированные промышленные технологии и гарантированно реализуемой в разумные сроки в силу высокой степени определенности, как в постановке задачи, так и в предлагаемых решениях.

Корпоративная сеть создается на многие годы вперед, капитальные затраты на ее разработку и внедрение настолько велики, что практически исключают возможность полной или частичной переделки существующей сети. Функциональные подсистемы, в отличие от корпоративной сети, изменчивы по своей природе, так как в предметной области деятельности организации постоянно происходят более или менее существенные изменения. Функциональность информационных систем сильно зависит от организационно-управленческой структуры организации, выполняемых функций и их распределения, принятых в организации финансовых технологий и схем, существующей технологии документооборота и множества других факторов.

Разработку и внедрение функциональных подсистем можно выполнять постепенно. Например, сначала на наиболее важных и ответственных участках выполнять разработки, обеспечивающие прикладную функциональность системы (внедрять системы финансового учета, управления кадрами и т.п.), а затем распространять прикладные программные системы и в других, первоначально менее значимых областях управления предприятием.

1.2. Классификация информационных систем

Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.

1.2.1. Классификация ИС по масштабу

По масштабу информационные системы подразделяются на следующие группы (рис. 1):

-одиночные;

-групповые;

-корпоративные.

Рис. 1. Деление информационных систем по масштабу

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.

Групповые информационные системы [шутки:8] ориентированы на коллективное использование информации членами рабочей группы и чаше всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура «клиент-сервер» [раздел 1.2.3: КС] со специализацией серверов или же многоуровневая архитектура [раздел 1.2.3: мног]. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз данных.

1.2.2. Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы (рис. 2):

- системы обработки транзакций;

- системы принятия решений;

- информационно-справочные системы;

- офисные информационные системы.

Рис. 2. Деление информационных систем по сфере применения

Системы обработки транзакций по оперативности обработки данных, в свою очередь, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций – OLTP (OnLine Transaction Processing), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями для них являются:

- высокая производительность обработки транзакций;

- гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.

Системы поддержки принятия решений — DSS (Decision Support System) представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: по временным, географическим и по другим показателям.

Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.

Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом.

1.2.3. Классификация по способу организации

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы (рис. 3):

- системы на основе архитектуры файл-сервер;

- системы на основе архитектуры клиент-сервер;

- системы на основе многоуровневой архитектуры;

- системы на основе интернет/интранет-технологий.

Рис. 3. Деление информационных систем по способу организации

В любой информационной системе можно выделить необходимые функциональные компоненты (табл. 1), которые помогают понять ограничения различных архитектур информационных систем. Рассмотрим более подробно особенности вариантов построения информационных приложений.

Таблица 1.

Типовые функциональные компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic (логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логики управления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

Архитектура файл-сервер

Архитектура файл-сервер не имеет сетевого разделения компонентов и использует клиентский компьютер для выполнения функций диалога и обработки данных, что облегчает построение графического интерфейса [шутки:14]. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к вычислительной сети.

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL [таблица 1:строка 3], а также логики обработки BL [таблица 1:строка 4] и управления данными DL [таблица 1:строка 5]. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

Однако такая архитектура имеет существенный недостаток: при выполнении некоторых запросов к базе данных клиенту могут передаваться большие объемы данных, которые загружают сеть и приводят к непредсказуемому времени реакции. Значительный сетевой трафик особенно сильно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи. Одним из вариантов устранения данного недостатка является удаленное управление файл-серверным приложением в сети. При этом в локальной сети размещается сервер приложений, совмещенный с телекоммуникационным сервером (обычно называемым сервером доступа), в среде которого выполняются обычные файл-серверные приложения. Особенность такой организации состоит в том, что диалоговый ввод-вывод поступает от удаленных клиентов через телекоммуникации. Приложения не должны быть слишком сложными, иначе велика вероятность перегрузки сервера, или же нужна очень мощная платформа для сервера приложений.

Архитектура клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры [раздел 1.2.3: ФС] путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД – наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS [таблица 1:строка 2] и PL [таблица 1:строка 3] размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS [таблица 1:строка 2], PL [таблица 1:строка 3] ), логики BL [таблица 1:строка 4] и DL [таблица 1:строка 5] – на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД – на сервере (рис. 4.).

Рис. 4. Классический вариант клиент-серверной информационной системы

Поскольку эта архитектура предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL [таблица 1:строка 4] можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура – процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.

Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность данных (нет прямого доступа к данным).

Создание архитектуры клиент-сервер возможно и на основе многотерминальной системы. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для UNIX. В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.

Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым проблемам в сложных информационных приложениях с множеством пользователей и запутанной логикой. Решением этих проблем может стать использование многоуровневой архитектуры.

Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер [раздел 1.2.3: КС] и в классической форме состоит из трех уровней (рис. 5)

- нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS [таблица 1:строка 2] и PL [таблица 1:строка 3] и имеющие программный интерфейс для вызова приложения на среднем уровне;

- средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL [таблица 1:строка 4] и с которого логика обработки данных DL [таблица 1:строка 5] вызывает операции с базой данных DS;

- верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS [таблица 1:строка 5] и файловых операций FS [таблица 1:строка 6] (без использования хранимых процедур).

Рис. 5. Классический вариант многоуровневой информационной системы

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и др.

Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер.

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе Microsoft Windows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.

Таким образом, многоуровневая архитектура распределенных приложений позволяет повысить эффективность работы корпоративной информационной системы и оптимизировать распределение ее программно-аппаратных ресурсов. Но пока на российском рынке по-прежнему доминирует архитектура клиент-сервер.

Интернет/интранет-технологии

В развитии технологии интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер – сервер приложений – сервер баз данных – сервер динамических страниц – web-сервер.

Благодаря интеграции Интернет/интранет-технологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.

1.3. Области применения и примеры реализации информационных систем

В последние несколько лет компьютер стал неотъемлемой частью управленческой системы предприятий. Однако современный подход к управлению предполагает еще и вложение денег в информационные технологии. Причем чем крупнее предприятие, тем больше должны быть подобные вложения.

Благодаря стремительному развитию информационных технологий наблюдается расширение области их применения. Если раньше чуть ли не единственной областью, в которой применялись информационные системы, была автоматизация бухгалтерского учета, то сейчас наблюдается внедрение информационных технологий во множество других областей. Эффективное использование корпоративных информационных систем позволяет делать более точные прогнозы и избегать возможных ошибок в управлении.

Из любых данных и отчетов о работе предприятия можно извлечь массу полезных сведений. И информационные системы как раз и позволяют извлекать максимум пользы из всей имеющейся в распоряжении компании информации.

Именно этим фактом и объясняются жизнеспособность и бурное развитие информационных технологий – современный бизнес крайне чувствителен к ошибкам в управлении, и для принятия грамотного управленческого решения в условиях неопределенности и риска необходимо постоянно держать под контролем различные аспекты финансово-хозяйственной деятельности предприятия (независимо от профиля его деятельности).

Поэтому можно вполне обоснованно утверждать, что в жесткой конкурентной борьбе большие шансы на победу имеет предприятие, использующее в управлении современные информационные технологии.

Рассмотрим наиболее важные задачи, решаемые с помощью специальных программных средств.

Бухгалтерский учет

Это классическая область применения информационных технологий и наиболее часто реализуемая на сегодняшний день задача. Такое положение вполне объяснимо. Во-первых, ошибка бухгалтера может стоить очень дорого, поэтому очевидна выгода использования возможностей автоматизации бухгалтерии. Во-вторых, задача бухгалтерского учета довольно легко формализуется, так что разработка систем автоматизации бухгалтерского учета не представляет технически сложной проблемы.

Управление финансовыми потоками

Внедрение информационных технологий в управление финансовыми потоками также обусловлено критичностью этой области управления предприятия к ошибкам. Неправильно построив систему расчетов с поставщиками и потребителями, можно спровоцировать кризис наличности даже при налаженной сети закупок, сбыта и при хорошем маркетинге. И наоборот, точно просчитанные и жестко контролируемые условия финансовых расчетов могут существенно увеличить оборотные средства фирмы.

Управление складом, ассортиментом, закупками

Далее, можно автоматизировать процесс анализа движения товара, тем самым отследив и зафиксировав те двадцать процентов ассортимента, которые приносят восемьдесят процентов прибыли. Это же позволит ответить на главный вопрос – как получать максимальную прибыль при постоянной нехватке средств?.

«Заморозить» оборотные средства в чрезмерном складском запасе – самый простой способ сделать любое предприятие, производственное или торговое, потенциальным инвалидом. Можно просмотреть перспективный товар, вовремя не вложив в него деньги.

Управление производственным процессом

Управление производственным процессом представляет собой очень трудоемкую задачу. Основными механизмами здесь являются планирование и оптимальное управление.

Автоматизированное решение подобной задачи дает возможность грамотно планировать, учитывать затраты, проводить техническую подготовку производства, оперативно управлять процессом выпуска продукции в соответствии с производственной программой и технологией.

Очевидно, что чем крупнее производство, тем большее число бизнес-процессов участвует в создании прибыли, а значит, использование информационных систем жизненно необходимо.

Управление маркетингом

Управление маркетингом подразумевает сбор и анализ данных о фирмах-конкурентах, их продукции и ценовой политике, а также моделирование параметров внешнего окружения для определения оптимального уровня цен, прогнозирования прибыли и планирования рекламных кампаний. Решения большинства этих задач могут быть формализованы и представлены в виде информационной системы, позволяющей существенно повысить эффективность управления маркетингом.

Документооборот

Документооборот является очень важным процессом деятельности любого предприятия. Хорошо отлаженная система учетного документооборота отражает реально происходящую на предприятии текущую производственную деятельность и дает управленцам возможность воздействовать на нее. Поэтому автоматизация документооборота позволяет повысить эффективность управления.

Оперативное управление предприятием

Информационная система, решающая задачи оперативного управления предприятием, строится на основе базы данных, в которой фиксируется вся возможная информация о предприятии. Такая информационная система является инструментом для управления бизнесом и обычно называется корпоративной информационной системой.

Информационная система оперативного управления включает в себя массу программных решений автоматизации бизнес-процессов, имеющих место на конкретном предприятии. Одно из наиболее важных требований, предъявляемых к таким информационным системам, – гибкость, способность к адаптации и дальнейшему развитию.

1.4. Методы проектирования информационных систем

На сегодня существует несколько методов проектирования [2] автоматизированных информационных систем (АИС).

1.4.1. Метод «снизу-вверх»

Менталитет российских программистов сформировался в крупных вычислительных центрах (ВЦ), основной целью которых было не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Этот подход во многом сохранялся и при автоматизации и сегодня. В условиях постоянно изменяющегося законодательства, правил ведения производственной, финансово-хозяйственной деятельности и бухгалтерского учета руководителю удобно иметь рядом посредника между спущенной сверху новой инструкцией и компьютером. С другой стороны, программистов, зараженных «вирусом самодеятельности», оказалось предостаточно, тем более что за такую работу предлагалось вполне приличное вознаграждение.

Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое «перетряхивание» инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и, как следствие, недовольство руководителей своими программистами несколько остудили пыл, и тех и других. Итак, первый подход сводился к проектированию «снизу-вверх». В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина «автоматизированного предприятия» просматривалась недостаточно хорошо, особенно в перспективе.

1.4.2. Метод «сверху-вниз»

Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном расчетно-кассовое обслуживание, для промышленных предприятий – автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС, безусловно, является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начало с детальной проработки данной проблемы. Системы были спроектированы «сверху», т.е. в предположении, что одна программа должна удовлетворять потребности всех пользователей.

Сама идея использования «одной программы для всех» резко ограничила возможности разработчиков в структуре информационных множеств базы данных, в использовании вариантов экранных форм и алгоритмов расчета, а следовательно, лишила возможности принципиально расширить круг решаемых задач – автоматизировать повседневную деятельность каждого работника. Заложенные «сверху» жесткие рамки (общие для всех) ограничивали возможности таких систем по ведению глубокого, часто специфического аналитического и производственно-технологического учета. Работники проводили эту работу вручную, а результаты вводили в компьютер. При этом интерфейс каждого рабочего места не мог быть определен функциями, возложенными на пользователя, и принятой технологией работы. Стало очевидно, что для успешной реализации задачи полной автоматизации банка следует изменить идеологию построения АИС.

1.4.3. Принципы «дуализма» и многокомпонентности.

Развитие промышленных предприятий, увеличение числа филиалов, рост количества клиентов, необходимость повышения качества обслуживания предъявляли к автоматизированным системам новые требования. Новый подход к проектированию АИС заключается в сбалансированном сочетании двух предыдущих.

С использованием гибкой системы настроек системного программного обеспечения (СПО) появилась реальная возможность адаптации программного аппарата практически к любым условиям работы и различным требованиям инструктивных материалов и правилам работы, принятым либо в вышестоящей организации, либо в данном банковском учреждении. Кроме того, при многокомпонентной схеме организации ИС при проведении модернизации одного из компонентов ее центральная часть ИС (ядро) и другие компоненты не затрагивались, что значительно повышало надежность, продолжительность жизни автоматизированной системы и обеспечивало наиболее полное выполнение требуемых функций.

Задача проектирования АИС промышленных предприятий сложна, так как характер обрабатываемой информации разнороден и сложно формализуем. Многокомпонентная система обеспечивала соблюдение основополагающего принципа построения автоматизированных информационных систем – отсутствия дублирования ввода исходных данных. Информация по операциям, проведенным с применением одного из компонентов системы, могла быть использована любым другим ее компонентом. Модульность построения АИС нового поколения и принцип одноразового ввода дают возможность гибко варьировать конфигурацию этих систем. Так, на предприятиях, имеющих разветвленную филиальную сеть и не передающих данные в режиме реального времени, установка всего СПО во всех филиалах не всегда экономически оправдана. В этих случаях возможна эксплуатация в филиалах ПО общего назначения, предназначенного для первичного ввода информации и последующей автоматизированной обработки данных в СПО, установленном в головном офисе. Такая структура дает возможность органически включить в ИС нового поколения компонент для создания хранилища данных, с разделением системы оперативного действия и системы поддержки принятия решения.

Кроме того, одно из достоинств принципа многокомпонентности, являющегося базовым при создании АИС нового поколения, состоит в возможности их поэтапного внедрения. На первом этапе устанавливаются (или заменяются уже устаревшие) компоненты системы на те рабочие места, которые нуждаются в обновлении ПО. На втором этапе происходит развитие системы с подсоединением новых компонентов и отработкой межкомпонентных связей. Возможность применения такой методики внедрения обеспечивает ее достаточно простое тиражирование и адаптацию к местным условиям. Таким образом, автоматизированная информационная система нового поколения – это многокомпонентная система с распределенной базой данных по уровням экспертизы.

2. ЖИЗНЕННЫЙ ЦИКЛ АИС

Разработка корпоративной информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, будут оказывать влияние на структуру информационной системы. Но в то же время структуры разных предприятий в целом похожи между собой. Каждая организация, независимо от рода ее деятельности, состоит из ряда подразделений, непосредственно осуществляющих тот или иной вид деятельности компании. И эта ситуация справедлива практически для всех организаций, каким бы видом деятельности они ни занимались.

Таким образом, любую организацию можно рассматривать как совокупность взаимодействующих элементов (подразделений), каждый из которых может иметь свою, достаточно сложную, структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В общем случае можно выделить три вида связей между подразделениями предприятия:

- функциональные связи – каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;

- информационные связи – подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);

- внешние связи – некоторые подразделения взаимодействуют с внешними системами, причем их взаимодействие также может быть как информационным, так и функциональным.

Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем.

В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:

- по содержанию действий разработчиков (групп разработчиков) – в данном случае рассматривается статический аспект процесса разработки, описываемый в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;

- по времени, или по стадиям жизненного цикла разрабатываемой системы – в данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов.

2.1.Общие сведения об управлении проектами

Информационная система предприятия разрабатывается как некоторый проект, Многие особенности управления проектами и фазы разработки проекта (фазы жизненного цикла) являются общими, не зависящими не только от предметной области, но и от характера проекта (неважно, инженерный это проект или экономический). Поэтому имеет смысл вначале рассмотреть ряд общих вопросов управления проектами.

2.1.1. Понятие проекта

Проект – это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенными целями, достижение которых определяет завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов и к организационной структуре.

Можно выделить следующие основные отличительные признаки проекта как объекта управления:

- изменчивость – целенаправленный перевод системы из существующего в некоторое желаемое состояние, описываемое в терминах целей проекта;

- ограниченность конечной цели;

- ограниченность продолжительности;

- ограниченность бюджета;

- ограниченность требуемых ресурсов;

- новизна для предприятия, для которого реализуется проект;

- комплексность – наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;

- правовое и организационное обеспечение – создание специфической организационной структуры на время реализации проекта.

Рассматривая планирование проектов и управление ими, необходимо четко осознавать, что речь идет об управлении неким динамическим объектом. Поэтому система управления проектом должна быть достаточно гибкой, чтобы допускать возможность модификации без глобальных изменений в рабочей программе.

В системном плане проект может быть представлен «черным ящиком», входом которого являются технические требования и условия финансирования, а итогом работы – достижение требуемого результата (рис. 6). Выполнение работ обеспечивается наличием необходимых ресурсов:

- материалов;

- оборудования;

- человеческих ресурсов.

Эффективность работ достигается за счет управления процессом реализации проекта, которое обеспечивает распределение ресурсов, координацию выполняемой последовательности работ и компенсацию внутренних и внешних возмущающих воздействий.

Рис. 6. Представление проекта в виде «черного ящика»

С точки зрения теории систем управления проект как объект управления должен быть наблюдаемым и управляемым, то есть выделяются некоторые характеристики, по которым можно постоянно контролировать ход выполнения проекта (свойство наблюдаемости). Кроме того, необходимы механизмы своевременного воздействия на ход реализации проекта (свойство управляемости).

Свойство управляемости особенно актуально в условиях неопределенности и изменчивости предметной области, которые нередко сопутствуют проектам по разработке информационных систем (более подробно проблемы получения полного формального описания предметной области будут обсуждаться в конце данной главы).

Для обоснования целесообразности и осуществимости проекта, анализа хода его реализации, а также для заключительной оценки степени достижения поставленных целей проекта и сравнения фактических результатов с запланированными существует ряд характеристик проекта. К важнейшим из них относятся технико-экономические показатели:

- объем работ;

- сроки выполнения;

- себестоимость;

- экономическая эффективность, обеспечиваемая реализацией проекта;

- социальная и общественная значимость проекта.

2.1.2. Классификация проектов

Проекты могут сильно отличаться по сфере приложения, составу, предметной области, масштабам, длительности, составу участников, степени сложности, значимости результатов и т. п. Проекты могут быть классифицированы по самым различным признакам. Отметим основные из них.

Класс проекта [шутки:16] определяется по составу и структуре проекта. Обычно различают:

- монопроект (отдельный проект, который может быть любого типа, вида и масштаба);

- мультипроект (комплексный проект, состоящий из ряда монопроектов и требующий применения многопроектного управления).

Тип проекта определяется по основным сферам деятельности, в которых осуществляется проект. Можно выделить пять основных типов проекта:

- технический;

- организационный;

- экономический;

- социальный;

- смешанный.

Масштаб проекта определяется по размерам бюджета и количеству участников:

- мелкие проекты;

- малые проекты;

- средние проекты;

- крупные проекты.

Можно также рассматривать масштабы проектов в более конкретной форме – отраслевые, корпоративные, ведомственные проекты, проекты одного предприятия.

2.2. Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы) [1].

В определении количества фаз и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки информационной системы почти во всех случаях являются общими.

Можно выделить следующие фазы развития информационной системы:

- формирование концепции;

- разработка технического задания;

- проектирование;

- изготовление;

- ввод системы в эксплуатацию.

Рассмотрим каждую из них более подробно.

Концептуальная фаза

Главным содержанием работ на этой фазе является определение проекта, разработка его концепции, включающая:

- формирование идеи, постановку целей;

- формирование ключевой команды проекта;

- изучение мотивации и требований заказчика и других участников [шутки:1];

- сбор исходных данных и анализ существующего состояния;

- определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов [шутки:11];

- сравнительную оценку альтернатив;

- представление предложений, их экспертизу и утверждение.

Разработка технического задания

Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком [шутки:5] о заключении контракта. Общее содержание работ этой фазы:

- разработка основного содержания проекта, базовой структуры проекта;

- разработка и утверждение технического задания;

- планирование, декомпозиция базовой структурной модели проекта;

- составление сметы и бюджета проекта, определение потребности в ресурсах;

- разработка календарных планов и укрупненных графиков работ;

- подписание контракта с заказчиком;

- ввод в действие средств коммуникации участников проекта и контроля над ходом работ.

Проектирование

На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов.

Характерные работы этой фазы:

- выполнение базовых проектных работ;

- разработка частных технических заданий;

- выполнение концептуального проектирования;

- составление технических спецификаций и инструкций;

- представление проектной разработки, экспертиза и утверждение.

Разработка

На этой фазе производятся координация и оперативный контроль работ по проекту, осуществляется изготовление подсистем, их объединение и тестирование. Основное содержание:

- выполнение работ по разработке программного обеспечения;

- выполнение подготовки к внедрению системы;

- контроль и регулирование основных показателей проекта.

Ввод системы в эксплуатацию

На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах.

Основные виды работ:

- комплексные испытания;

- подготовка кадров для эксплуатации создаваемой системы;

- подготовка рабочей документации, сдача системы заказчику и ввод ее в эксплуатацию;

- сопровождение, поддержка, сервисное обслуживание;

- оценка результатов проекта и подготовка итоговых документов;

- разрешение конфликтных ситуаций и закрытие работ по проекту;

- накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития.

Начальные фазы проекта имеют решающее влияние на достигаемый результат, так как в них принимаются основные решения, определяющие качество информационной системы. При этом обычно 30% вклада в конечный результат проекта вносят фазы концепции и предложения, 20% – фаза проектирования, 20% – фаза изготовления, 30% – фаза сдачи объекта и завершения проекта.

Кроме того, на обнаружение ошибок, допущенных на стадии системного проектирования, расходуется примерно в два раза больше времени, чем на последующих фазах, а их исправление обходится в пять раз дороже. Поэтому на начальных стадиях проекта разработку следует выполнять особенно тщательно.

Наиболее часто на начальных фазах допускаются следующие ошибки:

- ошибки в определении интересов заказчика;

- концентрация на маловажных, сторонних интересах;

- неправильная интерпретация исходной постановки задачи;

- неправильное или недостаточное понимание деталей;

- неполнота функциональных спецификаций (системных требований);

- ошибки в определении требуемых ресурсов и сроков;

- редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

2.3. Процессы, протекающие на протяжении жизненного цикла информационной системы

Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивается в момент полного изъятия ее из эксплуатации.

Существует международный стандарт, регламентирующий жизненный цикл информационных систем – ISO/IEC 12207.

Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:

- основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);

- вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование [шутки:4], управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем);

- организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).

Рассмотрим каждую из указанных групп более подробно

Основные процессы жизненного цикла

Среди основных процессов жизненного цикла наибольшую важность имеют три: разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.

Разработка

Разработка информационной системы включает в себя все работы по созданию информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает:

- оформление проектной и эксплуатационной документации; Q подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов;

- разработку материалов, необходимых для организации обучения персонала. Разработка является одним из важнейших процессов жизненного цикла информационной системы и, как правило, включает в себя стратегическое планирование, анализ, проектирование и реализацию (программирование).

Эксплуатация [шутки:21]

Эксплуатационные работы можно подразделить на подготовительные и основные.

К подготовительным относятся:

- конфигурирование базы данных и рабочих мест пользователей;

- обеспечение пользователей эксплуатационной документацией;

- обучение персонала.

Основные эксплуатационные работы включают:

- непосредственно эксплуатацию;

- локализацию проблем и устранение причин их возникновения;

- модификацию программного обеспечения;

- подготовку предложений по совершенствованию системы;

- развитие и модернизацию системы.

Сопровождение [шутки:12]

Службы технической поддержки играют весьма заметную роль в жизни любой корпоративной информационной системы. Наличие квалифицированного технического обслуживания на этапе эксплуатации информационной системы является необходимым условием для решения поставленных перед ней задач, причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой информационной системы.

Основными предварительными действиями при подготовке к организации технического обслуживания информационной системы являются следующие: выделение наиболее ответственных узлов системы и определение для них критичности простоя. Это позволит выделить наиболее критичные составляющие информационной системы и оптимизировать распределение ресурсов для технического обслуживания:

- определение задач технического обслуживания и их разделение на внутренние (решаемые силами обслуживающего подразделения) и внешние (решаемые специализированными сервисными организациями). Таким образом, производится четкое определение круга исполняемых функций и разделение ответственности;

- проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции. Основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала;

- подготовка плана организации технического обслуживания, в котором необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на этапах, ответственность исполнителей.

Обеспечение качественного технического обслуживания информационной системы требует привлечения специалистов высокой квалификации, которые в состоянии решать не только каждодневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях.

Вспомогательные процессы

Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией. Это один из вспомогательных процессов, поддерживающих основные процессы жизненного цикла информационной системы, прежде всего процессы разработки и сопровождения. При разработке проектов сложных информационных систем, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и, следовательно, иметь несколько вариантов реализации и/или несколько версий одной реализации, возникает проблема учета их связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты информационной системы на всех стадиях ее жизненного цикла.

Организационные процессы

Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля над сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает:

- выбор методов и инструментальных средств для реализации проекта;

- определение методов описания промежуточных состояний разработки;

- разработку методов и средств испытаний созданного программного обеспечения;

- обучение персонала.

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов информационной системы.

Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

Проверка – это процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик информационной системы исходным требованиям.

2.4. Структура жизненного цикла информационной системы

Полный жизненный цикл информационной системы включает в себя, как правило, анализ, проектирование, кодирование (программирование), тестирование, внедрение и эксплуатацию [раздел 2.2].

Главная особенность индустрии АИС состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно.

Анализ требований является первой фазой разработки АИС, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем АИС известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.

Список требований к разрабатываемой системе должен включать:

- совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение):

- описание выполняемых системой функций;

- ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).

Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются:

- архитектура системы [раздел 1.2.3], ее функции, внешние условия, распределение функций между аппаратурой и АИС;

- интерфейсы и распределение функций между человеком и системой;

- требования к программным и информационным компонентам АИС, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонент АИС, их интерфейсы.

Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?». Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как «(итерационный) процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям». Обычно этот этап разделяют на два подэтапа:

- проектирование архитектуры АИС [раздел 1.2.3], включающее разработку структуры и интерфейсов компонент, согласование функций и технических требований к компонентам, методам и стандартам проектирования, производство отчетных документов;

- детальное проектирование, включающее разработку спецификаций каждой компоненты, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонент.

В результате деятельности на этапах анализа и проектирования должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета выделенных ресурсов и времени.

В ходе этапа кодирования (программирования), отталкиваясь от результатов проектирования, реализуем систему в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т. д.

Более конкретно, целью кодирования является:

- Планирование необходимой на каждой итерации сборки системы. Мы используем инкрементный подход к разработке, результатом чего является реализация системы посредством последовательности малых управляемых шагов.

- Распределение системы путем отображения исполняемых компонентов на узлы модели размещения. Эта деятельность базируется на активных классах, обнаруженных в ходе анализа.

- Реализация классов и подсистем проектирования, обнаруженных в ходе проектирования, Так, классы проектирования реализуются в виде файлов компонентов, содержащих исходные тексты программ.

В рабочем процессе тестирования проверяются результаты реализации путем тестирования каждого билда, включая как внутренние и промежуточные, так и финальные версии системы, передаваемые внешним агентам.

Задачей тестирования является:

- Планирование тестов, необходимых на каждой итерации, включая тесты на целостность и системные тесты. Тесты на целостность необходимо проводить после каждого билда, в то время как системные тесты требуются только в конце итерации.

- Проектирование и реализация тестов для создания тестовых примеров, определяющих предмет тестирования, процедур тестирования, определяющих метод проведения тестирования, и, по возможности, – исполняемых тестовых компонентов для автоматизации тестирования.

- Проведение разнообразных тестов и систематическая обработка результатов каждого теста. Билды, в которых обнаруживаются дефекты, подвергаются повторному тестированию. После этого может произойти возврат к предшествующим рабочим процессам с целью исправления серьезных ошибок.

В фазе эксплуатации и сопровождения внимание сосредоточено на том, чтобы способствовать утверждению продукта в сообществе пользователей. Способ, которым это делается, зависит от сущности отношений программы и ее рынка. Так, если программа выводится на массовый рынок, команда разработчиков распространяет бета-версию среди типичных пользователей, найденных на специальных площадках, где «водятся» бета-тестеры. Если продукт предназначен для одиночного клиента или нескольких площадок в крупной организации, команда устанавливает продукт на одной из этих площадок.

Основные задачи этой фазы:

- сравнить функциональность системы, разработанной на предыдущих фазах, с требованиями и выяснить степень удовлетворенности заинтересованных лиц;

- рассмотреть все вопросы, необходимые для работы пользователей с системой, включая недостатки, сообщения о которых приходят от бета-тестеров и группы приемо-сдаточного тестирования.

Команда готовится к тиражированию продукта, разбивке его по пакетам, развертыванию и резервному копированию, и восстановлению системы. На этой фазе мы не вносим в продукт коренных изменений. Команда разработчиков и клиент должны вносить серьезные изменения в требования на более ранних фазах. Однако команда отыскивает небольшие недостатки, которые не были замечены на фазе построения и могут быть исправлены в рамках существующего базового уровня.

В обязанности команды по отношению к клиенту может также входить предоставление поддержки при создании подходящей для работы с проектом среды и обучение организации клиента правильному использованию продукта. Команда может оказывать пользователям помощь при параллельной работе с новой системой и с той унаследованной системой, которую она заменяет. Также она может способствовать конверсии баз данных в новую конфигурацию.

В случае если продукт предназначен для широкого распространения (рынок коробочных продуктов), эти сервисы обычно встраиваются в программу установки, которая является частью продукта и поддерживается службой поддержки. Фаза внедрения завершается выпуском продукта.

Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе жизненного цикла порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходными. Сведем данные по каждому этапу в итоговую таблицу.

Таблица 2. Жизненный цикл АИС.

№	Наименование этапа	Основные характеристики
1	Разработка и анализ бизнес-модели	Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС.
2	Формализация бизнес-модели, разработка логической модели бизнес-процессов.	Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Relationship) – CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
3	Выбор лингвистического обеспечения, разработка программного обеспечения АИС.	Разработка АИС: выбирается лингвистическое обеспечение (среда разработки – инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы – в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС.
4	Тестирование и отладка АИС	На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.
5	Эксплуатация и контроль версий	Особенность АИС созданных по архитектуре клиент сервер [раздел 1.2.3:КС] является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС

2.5. Модели жизненного цикла информационной системы.

Моделью жизненного цикла информационной системы будем называть некоторую структуру, определяющую последовательность осуществления процессов, действий и задач, выполняемых на протяжении жизненного цикла информационной системы, а также взаимосвязи между этими процессами, действиями и задачами.

В стандарте ISO/IEC 12207 не конкретизируются в деталях методы реализации и выполнения действий и задач, входящих в процессы [раздел 2.3] жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области.

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим выделяют три следующие модели ЖЦ:

1. Каскадная модель [раздел 2.5.1] (70-80г.г.) – предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.

2. Поэтапная модель с промежуточным контролем (80-85г.г.) – итерационная модель разработки АИС с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.

3. Спиральная модель [раздел 2.5.2] (86-90г.г.) – делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

К настоящему времени наибольшее распространение получили следующие две основные модели жизненного цикла:

- каскадная модель, иногда также называемая моделью «водопад» (waterfall);

- спиральная модель.

2.5.1. Каскадная модель [шутки:6] жизненного цикла информационной системы

Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные методы проектирования хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографиях, стандартах, учебниках. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими.

Каскадная модель предусматривает последовательную организацию работ. При этом, основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будут полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации [шутки:3], достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Основные этапы разработки по каскадной модели

За десятилетия существования модели «водопад» разбиение работ на стадии и названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее, все же можно выделить ряд устойчивых этапов [раздел 2.2] разработки, практически не зависящих от предметной области (рис. 7):

- анализ требований заказчика;

- проектирование;

- разработка;

- тестирование [шутки:19] и опытная эксплуатация;

- сдача готового продукта.

Рис. 7. Каскадная модель разработки

На первом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.

На втором этапе разрабатываются проектные решения, удовлетворяющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реализации проекта.

Третий этап – реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт.

На четвертом этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы информационной системы.

Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования реализованы в полной мере.

Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов.

Основные достоинства каскадной модели

Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»:

- на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное;

- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.

Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и при построении определенных информационных систем. Имеются в виду системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы реального времени.

Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно применением последовательного процесса разработки.

Недостатки каскадной модели

Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:

- существенная задержка получения результатов;

- ошибки и недоработки на любом из этапов выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие стадии;

- сложность распараллеливания работ по проекту;

- чрезмерная информационная перенасыщенность каждого из этапов;

- сложность управления проектом;

- высокий уровень риска и ненадежность инвестиций.

Задержка получения результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Поэтому может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей. Причем такие несоответствия могут возникать на любом этапе разработки – искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязательно хорошо разбираются в тех предметных областях, для которых производится разработка

Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации.

Возврат на более ранние стадии. Данный недостаток каскадной модели, в общем-то, является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы.

Самым же неприятным является то, что недоработки предыдущего уровня могут обнаруживаться не сразу на последующем уровне, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области). Это означает, что часть проекта должна быть возвращена на начальный уровень работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап, поэтому в реальном случае каскадная схема разработки имеет вид, приведенный на рисунке 8.

Рис. 8. Реальный процесс разработки по каскадной схеме

Одной из причин данной ситуации является то, что в качестве экспертов, участвующих в описании предметной области, часто выступают будущие пользователи системы, которые нередко не могут четко сформулировать то, что они хотели бы получить. Кроме того, заказчики и исполнители часто неправильно понимают друг друга вследствие того, что исполнители обычно не являются специалистами в предметной области решаемой задачи, а заказчики далеки от программирования.

Сложность параллельного ведения работ. Отмеченные выше проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последовательных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг от друга группы разработчиков. Поэтому преимущества параллельного ведения работ просто теряются.

Отсутствие параллелизма негативно сказывается и на организации работы всего Коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не имеют работы. Кроме того, при последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передаче проекта на следующую стадию. Так, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Это связано с тем, что более раннее решение уже, возможно, реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка проекта после его передачи на следующий этап.

Информационная перенасыщенность. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли использовать эту часть в своей работе. Когда система состоит из большого количества взаимосвязанных подсистем, то синхронизация внутренней документации становится важной самостоятельной задачей.

Причем синхронизация документации на каждую часть системы – это не более чем процесс оповещения групп разработчиков. Самим же разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения, на уже полученных результатах. Все это может потребовать проведения повторного тестирования, и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации и разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней.

Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе выполнения разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела.

Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта.

Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для того, чтобы согласовать сроки работы и состав передаваемой документации.

В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени.

Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, уменьшая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабосвязанных подсистем.

Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки – этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено выше, запоздалая оценка создает значительные проблемы при выявлении ошибок анализа и проектирования – требуется возврат проекта на предыдущие стадии и повторение процесса разработки.

Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими за время выполнения разработки в предметной области или в требованиях заказчика. Причем возврат проекта вследствие этих причин на доработку не гарантирует, что предметная область [шутки:15] снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится» и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта – постоянно откладываться. Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой компании The Standish Group, в США более 31 % проектов корпоративных информационных систем (IT-проектов) заканчивается неуспехом; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189 %, то есть почти в два раза); и только 16,2 % проектов укладывается и в срок, и в бюджет.

2.5.2. Спиральная модель жизненного цикла [шутки:18]

Спиральная модель, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы. При этом возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов.

Итерации

Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой (рис. 9).

Рис. 9. Итерации

Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. На каждой итерации углубляются и последовательно конкретизируются детали проекта, в результате чего выбирается обоснованный вариант, который доводится до окончательной реализации.

Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работы на текущем – недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации – как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.

Преимущества спиральной модели

Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели [раздел 2.5.1] и, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким.

Рассмотрим преимущества итерационного подхода более подробно:

- итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

- при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40% всех затрат в конце проекта);

- уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция производится уже на первой итерации. При выполнении начальных итераций выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т. п. На рисунке 10 приведены в сравнении графики зависимости уровня рисков от времени разработки при использовании каскадного и итерационного подходов;

- итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет уменьшения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным в условиях конкурентной борьбы, когда необходимо противостоять продвижению изделия, предлагаемого конкурентами;

Рис. 10. Зависимость рисков от времени разработки

- итерационный подход упрощает повторное использование компонентов (позволяет использовать компонентный подход к программированию). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться;

- спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что при использовании каскадной модели [раздел 2.5.1] выполняется только перед внедрением системы;

- итерационный подход позволяет совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.

Проблемы, возникающие при использовании спиральной модели

Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее – враг хорошего». Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена. Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

3. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ

Целью предпроектного обследования [раздел 2.2: концептуальная фаза] является исследование организационной структуры, изучение систем управления, формирование информационных потоков [6]. По результатам обследования производится разработка мероприятий по устранению недостатков и формирование перечня новых решений автоматически. В процессе обследования рассматривается организационная и функциональная сторона объекта, разрабатываются предложения по их оптимизации. Сбор данных об объекте автоматизации и осуществляемых видах деятельности позволяет досконально изучить и обнаружить все узкие места прохождения информационных потоков с целью их дальнейшей оптимизации. При обследовании информационных потоков выделяют 2 подхода:

- организационный – когда анализируется потоки информации по структурным элементам предприятия;

- функциональный – кода анализируются информационные потоки по отдельным процедурам и задачам.

Предпроектное обследование затрагивает как операции управления, так и потоки информации. Обследование проводится по специальной программе с использованием определенных методик и документирования результатов. Процесс обследования согласуется с принятой стратегией создания системы.

Децентрализованная стратегия или функциональный подход заключается в последовательном проектировании функциональных подсистем. Для каждой из них создается автономная информационная база. Эта стратегия обеспечивает быстрое внедрение функциональных подсистем, однако, оптимальная организация информационного обеспечения и автоматизация информационной системы в целом рассчитывается с меньшей вероятностью.

Централизованная стратегия предполагает создание интегрированной базы данных, является основой разработки функций и задач автоматизированного управления.

В соответствии децентрализованной стратегией предпроектное обследование предприятия может проводиться путем исключения. Звеньями организационной структуры являются подразделения предприятия (отделы, цеха и т. д.). Функциональными звеньями являются функции управления функциональными подразделениями.

Централизованная стратегия делает упор на информационном анализе предметной области, изучение состава и структуры информационных потоков с целью их интеграции.

Рекомендации по созданию АСУ вырабатываются обобщением всех выводов и рекомендаций, полученных в результате предпроектного обследования. Все мероприятия по совершенствованию управления делятся на 2 группы:

- те, которые могут быть реализованы программами по внедрению АС;

- те, которые требуют внедрения разного рода средств автоматизированного управления.

Основными направлениями в совершенствовании управления является:

- упрощение организационной структуры, благодаря упразднениям излишних промежуточных звеньев и многоступенчатости;

- повышения централизованного управления;

- децентрализация;

- введение базовой структуры управления на небольших предприятиях;

- совершенствование системы документооборота, т.е. устранение лишних реквизитов и документов, сокращение их маршрутов.

3.1. Функциональная структура компонентов объектов автоматизации

В процессе предпроектного обследования и анализа материалов обследования изучается функциональная структура объекта автоматизации, то есть состав подсистем, состоящих из комплекса задач и процедур управления.

Задачи комплекса функционально и информационно связаны друг с другом. Решение задач организуется на системных принципах АИС. Различаются такие функции управления: планирование, учет, контроль, анализ, реструктурирование. Звеном внешнего уровня функциональной структуры предприятия является функция управления. При создании АИС функции управления реализуются через функциональные подсистемы. Функциональная подсистема – часть системы, включающая внутреннюю по определенному признаку совокупность задач, характеризующихся единством результатов в процессе управления.

Функциональная задача определяется как совокупность взаимосвязанных аппаратов управления, обеспечивая получение результата в виде одного или нескольких документов для цепи управления.

3.2. Методы обследования управленческих процедур

Изучению управленческих процедур предшествует ознакомление с предметной областью в целом. При этом рассматриваются существующие производственные и технические процессы, а также материальные потоки, организационная структура управления, состав подразделений, их подчиненность друг другу и назначение. В зависимости от вида объектов оценивается их технико-экономические показатели, отражающие специфику деятельности предметной области. Для простого предприятия это номенклатура выпускаемой продукции, количество технологических процессов при изготовлении изделий, номенклатура материальных ресурсов, то есть количество видов, объемы запасов и объемы материальных ресурсов.

Реализация управленческих функций осуществляется через решение задач управления. Функции задач управления связаны с деятельностью управляющего персонала и отражают организационную структуру органов управления, то есть состав подразделений или лиц принимающих решение. При обследовании существующей системы управления необходимо установить:

- состав, периодичность и условие включения каждой управленческой функции или задачи;

- число множителей функции управления;

- трудоемкость и сложность работы управляющего персонала;

- примененные технические средства обработки информации для выполнения управленческих функций;

- должностные инструкции, штатное расписание и структуру управления, то есть состав подразделений, оценка их деятельности, взаимосвязи по выполняемой функции управления;

- нормативно-справочная информация.

В результате мы получим цели деятельности каждого структурного подразделения и предприятия в целом. Это может быть обеспечением стабильного дохода, конкурентоспособности продукции, сокращение рабочего времени и так далее. Установившиеся цели деятельности, а также критерии их достижения. Определение функциональной подсистемы управления и состав задач.

Существует несколько методов, пригодных для обеспечения всех функциональных звеньев предприятия.

Важными являются следующие:

- метод наблюдений;

-метод опроса исполнителей;

- анализ материалов (анкетирование);

- метод личного участия.

Они применяются, как правило, в различных сочетаниях и предполагают разную степень личного участия проектировщика в обследовании.

Метод наблюдений

Применяется тогда, когда изучаемый вопрос практически понятен и требуется лишь уточнить некоторые детали. Самый распространенный, хотя имеет недостатки. В процессе опроса приходится отвлекать людей от работы, а полученные сведения могут быть неточными. Метод рекомендуется применять, когда требуется уточнить какие-либо неясности в вопросе при условии, что опрос существенно облегчит труд проектировщика.

Метод анализа материалов

Является наиболее точным и научно обоснованным. Материалы собираются затем обрабатываются и анализируются по определенным научно-разработанным методикам. Примером метода является анализ информационных потоков.

Метод личного участия

Является наиболее достоверным, так как предполагает выполнение производственных операций лично проектировщиком. Минусом является увеличение сроков и сложность обеспечения.

Метод функционально-информационного анализа

Позволяет проследить и проверить образованную цепочку функциональной структуры автоматизированной объекта управления. По существу это восходящее проектирование системы. Он предназначен для обеспечения информационных потоков в функциях задач или процедур, для которых организация звеньев применяется.

3.3. Исследование потоков и структура информации

В процессе предпроектного обследования изучается состав, структура, форма и содержание информационных сообщений, а также информационные процессы, охватывающие сбор и регистрацию первичной информации, передачу данных, обработку сообщений, организацию хранения и доступа к информации для подготовки и принятия управленческих решений. Информационный анализ предметной области выполняется в трех направлениях:

- смысловое содержание сообщения, их информативность для цепи управления;

- состав и структура сообщения, правила их построения на внемашинном и внутримашинном уровне;

- полезность сообщения для целей управления, выполнение функций управления к решению управленческих задач.

3.3.1. Обследование документов и документооборота в системах управления

В процессе обследования необходимо создать единый альбом формы документов и установить важнейшие характеристики каждого документа.

- система документации, к которой относится документ(конструкторская, техническая, отчетно-статистическая, первично-учетная);

- форма документа – для ручного заполнения это бланк, а для машинного экранная форма;

- реквизитный состав документа или структура записи массива информации на машинном носителе;

- характеристики объема информации документа – количество экземпляров документа, количество строк в документе через фиксированный интервал времени;

- схема документооборота, которая отражает состав и последовательность выполнения процедур.

Изучение основных единиц информации, реквизитов входных и выходных документов, полей записи файлов информационной базы позволяет установить форматные характеристики данных и выявить структуру данных. Основными семантическими характеристиками реквизита являются:

- наименование реквизита;

- условное обозначение (код);

- тип и формат значений реквизита;

- диапазон допускаемых значений.

Все реквизиты сводятся в единый справочник по всем формам документа, что позволяет проанализировать структуру данных.

Анализ нормативно-справочного обеспечения

К нормативно-справочному обеспечению (НСО) систем управления относятся:

- классификаторы;

- номенклатурные справочники;

- массивы норм и нормативы.

Изучение начинается с анализа систем классификации и кодирования. При этом устанавливаются:

- обозначения и наименования классификаторов;

- исходное множество объектов – продукция, материалы и т.д.;

- область действия классификатора (государственный, отраслевой, локальный);

- метод классификации, принципы и основные деления;

- алфавит и структура кода;

- помехозащищенность кода;

- емкость системы классификации – количество классификационных группировок.

На основе этих признаков дается оценка пригодности существующих классификаторов информационной системы, вживляются недостающие элементы исходя из информационных потребностей задачи.

Изучение организации внутримашинной информационной базы

Изучение состава и структуры базы выполняется по следующим направлениям:

- структура внутримашинной информационной базы – файловая организация, БД;

- состав и структура массивов информации на машинных носителях;

- объем информации;

- программные средства для создания и ведения информационной базы.

Дополнительно устанавливаются:

- особенности организации сбора и обработки информации;

- трудозатраты на ввод и редактирование данных;

- эксплутационные характеристики существующей системы обработки информации:

o среднее время ожидания информации на запрос пользователя,

o производительность информационной системы,

o минимально-необходимые вычислительные ресурсы;

- требования к качественным характеристикам информации:

o уровень достоверности,

o актуальность информации (задержки записи оперативных сведений в ИБ),

o доступность восприятия, форма представления выходной информации.

Рис. 11. Структура информационных потоков

Метод анализа материалов

Для документооборота пользуемся технологией реестра. Реестр входящей информации, выходящей и внутренней. Каждый из участников получает по три реестра. Реестр – список документов, с которыми работает человек и их образцы.

Состав реестра:

- наименование документа;

- количество документов за период;

- физическое представление;

- время оперативного использования;

- срок хранения;

- подразделение, отдел или внешняя организация, куда отправляется информация;

- лица, имеющие доступ к документу по порядку прохождения.

При заполнении реестра надо все правильно указать, чтобы потом сделать анализ. Кроме реестра всем участвующим выдают анкету, в которой надо охарактеризовать подразделение и выполняемые сотрудниками функции.

Методика сбора документации при обследовании

Предпроектное обследование производится в 3 этапа:

- распространение материала;

- сбор материала на местах;

- передача материала проектировщикам.

После определения методик обследования производят формирование раздаточного материала, с которым будут работать участники обследования. Задание представляет собой папку с подборкой материалов, представленных для распределения и обработки среди участников обследования, папка содержит:

- рекомендации руководителю предприятия;

- инструкции по размножению материала;

- анкета;

- инструкции по заполнению анкет;

- реестр, входящей информации;

- внутренний реестр;

- реестр исходящей информации;

- инструкции к реестрам;

- реестр сдачи заполненных материалов;

- инструкция по организации сдачи материалов.

3.4. Порядок проведения обследования на объекте

1. Проведение рабочих семинаров с руководителями и ответственными лицами. На семинарах руководители отделов объясняют методику обследования, назначаются ответственные лица, утверждаются сроки проведения, происходит выдача материала.

2. Проведение организационных работ по подготовке к выполнению задания. Ответственные лица обязаны решать все организационные вопросы в процессе проведения обследования, контролировать сроки выполнения.

- Размножение документов. Ответственные лица организовывают размножение документов с выданных образцов. Количество копий должно соответствовать количеству отделов и служб. Размножение материала распространяется по отделам в соответствии с инструкцией.

- Выдача размноженного материала. Материал раздают начальники отделов, которые разбивают отдел на сектора, производится размножение материала для каждого сектора. Аналогичный процесс происходит в секторах.

3. Сбор материалов. После окончания обработки ответственные лица собирают материал, организуя общий пакет данных о предприятии. Сбор производится по принципу «снизу вверх». Собранные данные группируются на сектора и так далее.

4. Передача данных проектировщику. После чего проектировщиком проверяется качество и полнота материалов.

Первичная обработка материала.

Материалы позволяют выявить существующие информационные потоки и их характеристики. На основании этих данных можно смоделировать взаимодействие между различными структурными элементами системы, затем выявить те, которые целесообразно рассматривать как объект автоматизации.

Для проведения информационного анализа надо провести кодирование полученной документации.

4. ЦЕЛИ, ЗАДАЧИ И МЕТОДЫ ПРОЕКТИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ CASE-ТЕХНОЛОГИЙ

Моделирование работы информационной системы особенно важно на первых этапах ее создания, так как допущенные на этом этапе ошибки обходятся особенно дорого, то и польза на этом этапе от качественного анализа задачи и разработки логической модели значительна.

За последнее время сформировалось новое направление в области инструментального ПО – CASE-средства [4]. CASE – это технология, представляющая совокупность методологий создания, анализа, проектирования и сопровождение ПО.

CASE – инструментарий для системных аналитиков [шутки:17], разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер, для автоматизации проектирования и разработки ПО.

CASE-средства, позволяют получить описание работы, создаваемой системы, раньше ее построения или создания. Потом с их помощью можно анализировать работу системы и оптимизировать подготавливаемые решения. Для этого специально предусмотрен инструментарий проектирования.

Использование CASE-средств еще не гарантирует качество проектирования, CASE-средства – это своеобразная и очень мощная поддержка мышления, развитие логики. На базе чего возможности аналитиков значительно расширились.

Обработка результатов обследования и построение модели деятельности предприятия реализуется в двух видах.

«Как есть»

Представляет собой «снимок» положения дел на предприятии (организационно штатная структура, взаимодействие подразделений и т.д.) на момент обследования и позволяющий понять, как идут дела и как функционирует предприятие с позиций системного аналитика, а также на основе автоматизированной верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по улучшению ситуации.

«Как должно быть»

Интегрирующие и перспективные предложения руководителей и сотрудников предприятия, экспертов и системных аналитиков, позволяют организовать введение новых рациональных технологий работы предприятия.

Каждая из моделей включает в себя полную структурно-функциональную модель деятельности (например: в виде иерархии диаграмм потоков данных, с разработками для всех процессов нижнего уровня подробными их спецификациями на структурированном естественном языке в виде SADT [3] диаграмм).

Каждый аналитик, приступивший к анализу системы должен ориентироваться на минимальный набор стартовых условий, в состав которых входит:

- информация об объекте проектирования, то есть информационная система как черный ящик;

- знание о предметной области, в которой работает предприятие (они могут быть получены путем предварительного изучения объекта или на основании анкет);

- знание об эталонных процедурах выполнения ключевых процессов в соответствии с международными или национальными стандартами;

- знание о методах и средствах моделирования и анализа систем;

- программные средства (инструментарий) для моделирования и анализа;

- ограничение на создаваемую систему, связанные с реальными возможностями и существующими традициями предприятия (особенно финансирование, корпоративной культуры).

Формальный перечень работ, которые необходимо выполнить на начальных этапах анализа системы практически не зависит от того, какие методологии и инструменты будут использованы для моделирования и анализа. От инструмента зависит лишь результат.

В процессе разработки информационной системы выполняется ряд задач уровня анализа, каждый из которых соответствует трем основным моделям информационной системы:

- определение требований;

- формирование спецификаций;

- внедрение.

При выполнении работ по моделированию на каждом из трех уровней могут быть использованы различные инструментальные средства. Вместе с тем необходимость комплексного анализа при создании информационной системы оказывает существенное влияние на выбор инструментов моделирования.

Классификация CASE-средств

Инструментальные средства, предназначены для моделирования информационных систем, могут быть отнесены к любой из следующих категорий.

Локальные, покрывающие один-два типа моделей и методов (DESION \ IDEF, PROCAP, S-DESIGNER, CASE-аналитик). При разработке информационных систем локальные средства моделирования могут быть использованы только на концептуальном уровне для предварительного анализа или для демонстрации общих положений проекта.

Малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERWIN, BPWIN). Эта категория почти, как и первая, но в полной мере позволяет выполнить комплексный анализ системы. С их помощью можно разрабатывать локальные ИС и крупные ИС, но с выделением на подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, когда нет необходимости в комплексном анализе. Малые интегрированные средства – для них характерны некоторые особенности: наличие в инструментальном средстве независимых компонент и интеграция модели путем экспорта \ импорта данных

BPWIN поддерживает 3 методологии моделирования:

- структурное моделирование IDEF0;

- моделирование процессов IDEF3;

- диаграмма потоков данных DFD.

Эти методологии обеспечивают интеграцию моделей 3-х типов. Без экспорта/импорта данных интеграция выполняется путем слияния нескольких моделей и/или посредством переключения на разные методологии. В процессе разработки основных диаграмм моделей. ERWIN поддерживает несколько разновидностей методологий моделирования, основанных на ER-диаграммах (сущность-связь). BPWIN и ERWIN обмениваются данными.

Средние интегрированные средства моделирования, поддерживающие до 10 – 15 моделей и методов (RATIONAL ROSE, PARADIGM PLUS, DESIGNER 2000). В эту категорию заложены средства комплексного использования различных методов и типов моделей. Продукты этой интеграции имеют единую среду для разработки всех поддерживаемых типов моделей, что позволяет применять одни и те же объекты в разных типах моделей. Rational Rose основан на объектно-ориентированном подходе к моделированию и ориентирован на UML (Unique Modeling Language). Rational Rose позволяет строить 8 видов диаграмм:

- диаграммы прецедентов;

-диаграммы классов;

- диаграммы последовательностей;

- диаграммы сотрудничества;

- диаграммы состояний;

- диаграммы действий;

- компонентные диаграммы;

- диаграммы развертывания.

Средства 3-го класса предназначены для комплексного анализа системы.

Крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset). Группа предназначена для разработки крупных ИС. ARIS обеспечивает четыре различных типа взгляда на моделирование и анализ разрабатываемых ИС.

4.1 Создание модели данных с помощью ERwin [раздел 4:классификация:малые интегрированные]

4.1.1 Отображение модели данных в ERwin

ERwin имеет два уровня представления модели – логический и физический.

Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах – таблицах, колонках, индексах, процедурах и т. д. Разделение моделей данных на логические и физические позволяет решить несколько важных задач.

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов – пробела и т. п.). Зачастую разработчики имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением – только одним словом).

Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы – имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость – создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой.

ERwin имеет несколько уровней отображения диаграммы:

- уровень сущностей;

- уровень атрибутов;

- уровень определений;

- уровень первичных ключей;

- уровень иконок.

Для создания моделей данных в Erwin можно использовать две нотации:

IDEF1X

IE (Information Engineering)

Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США, финансовых и промышленных корпорациях. Методология IE, разработанная Мартином, Финкельштейном и другими авторами, используется преимущественно в промышленности.

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий «Сущность-связь» (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных.

4.1.2. Создание логической модели данных

Уровни логической модели

Основные компоненты диаграммы Erwin – это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.

Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить «технических» наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели.

Различают три уровня логической модели, отличающихся по глубине представления информации о данных:

- диаграмма сущность-связь (Entity Relationship Diagram, ERD);

- модель данных, основанная на ключах (Key Based model, KB);

- полная атрибутивная модель (Fully Attributed model, FA).

Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям. Диаграмма сущность-связь может включать связи «многие ко многим» и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

Модель данных, основанная на ключах, – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

Понятие сущности

Так как в ERwin для моделирования данных используется методология ER [9] (Entity Relational), давайте начнем с краткого введения в концепции ER. Для начала приступим к изучению сущностей – «контейнеров» для хранения информации логической модели.

Для визуального представления сущностей и отношений между ними используются ERD-диаграмма (Entity Relational Diagram - реляционная диаграмма сущности), основанная на нотации, используемой ERwin. Хотя существуют и другие методологии моделирования данных, такие как расширенный реляционный анализ (Extended Relational Analysis - ERA), объектно-ориентированный подход (Object Oriented - OO) и объектно-ролевое моделирование (Object Role Modeling - ORM), фундаментальные концепции ER методологии присутствуют и в них.

Методология ER-моделирования разработана П. Ченом в конце 1970-х годов [7]. Для представления сущностей в методологии ER используются прямоугольники. В исходной ER-нотации Чена отношения содержат атрибуты. Равная возможность использования атрибутов в сущностях и отношениях делает различие между сущностями и отношениями достаточно сложным.

С течением времени ER-подход изменялся и расширялся, но базовые концепции продолжали обеспечивать надежную основу для грамотного моделирования данных.

Сущность – это физическое представление логической группировки данных. Сущности могут быть вещественными, реальными объектами, такими как ПЕРСОНА или МОРОЖЕНОЕ, или неосязаемыми концептуальными абстракциями как ЦЕНТР ЗАТРАТ или РЫНОК. Сущности не предназначены для представления единичного объекта, они представляют набор экземпляров, содержащих информацию, представляющую интерес с точки зрения их уникальности. Например, сущность ПЕРСОНА представляет собой экземпляр объектов типа Персона. Иван Петров, Мария Русанова и Савелий Богданов - конкретные примеры экземпляров сущности ПЕРСОНА. Конкретный экземпляр сущности представляется строкой таблицы и идентифицируется первичным ключом.

Сущность имеет следующие признаки:

- она имеет имя и описание;

- она представляет класс, а не единичный экземпляр абстракции;

- ее конкретные представители (экземпляры) могут быть уникально идентифицированы;

- она содержит логическую группировку атрибутов, представляющих информацию, интересную с точки зрения корпорации.

Формальные определения сущности

Ниже приведен список определений сущности признанных авторитетов в области моделирования данных. Обратите внимание на их сходство:

Чен (1976): «Вещь, которая может быть однозначно идентифицирована».

Финклештейн (1989): «Информационная сущность представляет некую «вещь», которая сохраняется для дальнейших ссылок. Термин сущность относится к логическому представлению данных».

Выделение сущностей

Как приступить к процессу выделения сущностей? Большинство сущностей выявляются в ходе рабочих сессий и интервью. Анализ требований к информации, полученной от экспертов в предметной области и конечных пользователей – вот наилучший источник информации. Другим хорошим источником является корпоративная модель.

Обратите внимание на имена существительные и имена объектов – вполне возможно, что они станут логическими сущностями. Старайтесь не представлять единичные экземпляры в виде сущностей, как это часто бывает, когда сущности моделируются в терминах роли. Моделирование сущностей в терминах роли – достаточно распространенная ошибка. Сущности появляются и в процессе нормализации. Приведение логической модели к третьей нормальной форме вероятнее всего приведет к появлению нескольких дополнительных сущностей.

Существует две основных группы сущностей: зависимые и независимые. Независимая сущность не нуждается в информации из другой сущности для идентификации уникального экземпляра. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая сущность должна привлекать информацию из другой сущности для идентификации уникального экземпляра. Она представляется на ER-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

Рис. 12. Примеры стержневых сущностей для корпорации, торгующей мороженым.

На рисунке 12 изображены прямые углы независимых сущностей МАГАЗИН и МОРОЖЕННОЕ и скругленные углы зависимой сущности МАГАЗИН МОРОЖЕННОГО.

Определение типов сущностей

И зависимые, и независимые сущности можно разделить на несколько типов:

- Стержневые сущности – их иногда называют основными или первичными сущностями. Они представляют важные объекты, информацию о которых следует хранить.

- Коды/ссылки/классификаторы – эти сущности содержат строки, определяющие набор значений или область определения для атрибута.

- Ассоциативные сущности – эти сущности используются для разрешения отношений многие-ко-многим.

- Характеристические сущности – эти сущности бывают двух типов: исключающие и включающие.

Стержневые сущности

Стержневые сущности представляют наиболее важные корпоративные информационные объекты. Их иногда называют первичными, главными или основными сущностями. Так как эти сущности чрезвычайно важны, то, скорее всего, они используются во многих подразделениях корпорации. Потратьте время на поиск сходных сущностей, поскольку для стержневых сущностей велика вероятность наличия возможности их повторного использования. В рамках корпорации стержневые сущности должны моделироваться единообразно. Хорошие разработчики моделей рассматривают такой подход как исключительно полезный.

Стержневые сущности могут быть как независимыми, так и зависимыми. На рисунке 12 представлены примеры стержневых сущностей для корпорации, торгующей мороженым. Сущность МОРОЖЕНОЕ представляет базовый продукт корпорации. Сущность МАГАЗИН является примером канала сбыта или посредника при продаже товара.

Предположим, что дела в корпорации идут хорошо и принимается решение об открытии дополнительного МАГАЗИНА. Для добавления новых экземпляров сущности МАГАЗИН нет необходимости менять модель. То же самое касается и сущности МОРОЖЕНОЕ.

Обратите внимание на стержневые сущности МОРОЖЕНОЕ и МАГАЗИН. Хотя пример может показаться несколько прямолинейным, он иллюстрирует всю мощь концепции, лежащей в основе моделирования стержневых сущностей. Понимание необходимости моделировать стержневые сущности в виде масштабируемых и расширяемых контейнеров требует от разработчика модели взгляда на сущности как на абстрактные концепции и моделирования информации независимо от текущего способа ее использования. В этом примере модель сущности МОРОЖЕНОЕ полностью вне контекста сущности МАГАЗИН и наоборот. Так что если в корпорации решат продавать МОРОЖЕНОЕ через новый канал сбыта, такой как Интернет или доставка на дом, новый канал сбыта может быть добавлен без изменений в других сущностях.

Кодовые сущности

Кодовые сущности всегда являются независимыми. Их часто называют ссылками, классификаторами или сущностями типов, в зависимости от используемой методологии. Уникальные экземпляры, представляемые кодовыми сущностями, определяют область определения для значений атрибутов, принадлежащих другим сущностям. Следует включать, по меньшей мере, три атрибута в кодовую сущность: идентификатор, имя (иногда его называют кратким именем) и определение.

На рисунке 13 ВЕРХУШКА – независимая сущность (обратите внимание на прямые углы). ВЕРХУШКА является к тому же кодовой сущностью или классификатором. Экземпляры (строки) сущности ВЕРХУШКА определяют список доступных верхушек.

Кодовые сущности обычно содержат ограниченное количество атрибутов. Существуют реализации, где эти сущности имели только один атрибут. Предпочтительно моделировать кодовые сущности с использованием искусственного идентификатора. Искусственный идентификатор вместе с именем и определением позволяют добавлять новые виды ВЕРХУШЕК в качестве экземпляров (строк) в сущность. Обратите внимание на три атрибута сущности ВЕРХУШКА.

Специалисты часто ссылаются на кодовые сущности, как на корпоративные бизнес-объекты. Термин корпоративный бизнес-объект указывает, что сущность определена и совместно используется на корпоративном уровне, а не на уровне единичного приложения, системы или подразделения организации. Эти сущности часто совместно используются многими базами данных для обеспечения целостного подхода к формированию сводных отчетов и при проведении анализа тенденций.

Рис. 13. Кодовая сущность.

Ассоциативные сущности

Ассоциативными являются сущности, которые содержат первичные ключи двух или более других сущностей. Ассоциативные сущности всегда зависимы. Они используются для разрешения отношений многие-ко-многим других сущностей. Отношения многие-ко-многим возникают в том случае, когда множество экземпляров одной сущности связаны с множеством экземпляров другой. Ассоциативные сущности позволяют нам моделировать пересечение экземпляров двух сущностей, обеспечивая уникальность каждого экземпляра ассоциации.

Отношения многие-ко-многим не могут быть реализованы в базе данных на физическом уровне. ERwin автоматически создает ассоциативные сущности для разрешения отношений многие-ко-многим при переходе от логической модели к физической.

На Рис. 12 ассоциативная сущность используется для разрешения отношения многие-ко-многим между сущностями МАГАЗИН и МОРОЖЕНОЕ. Введение ассоциативной сущности дает возможность использовать одно и то же МОРОЖЕНОЕ для продажи в нескольких экземплярах МАГАЗИНА, без необходимости продажи в каждом из МАГАЗИНОВ одинаковых сортов МОРОЖЕНОГО. Ассоциативная сущность МАГАЗИН МОРОЖЕНОГО учитывает тот факт, что экземпляр МАГАЗИНА продает множество экземпляров МОРОЖЕНОГО, и экземпляр МОРОЖЕНОГО может продаваться многими экземплярами МАГАЗИНА.

Характеристические сущности

Характеристические сущности всегда являются зависимыми. Вы должны использовать характеристические сущности там, где для экземпляров сущностей имеет смысл хранить различные наборы атрибутов. Финклештейн называет характеристические сущности вторичными сущностями. Характеристические сущности всегда имеют одну или более «равноправных» сущностей. Равноправные характеристические сущности связаны с родительской сущностью особым типом отношений, которые могут быть исключающими или включающими.

Равноправные характеристические сущности, которые находятся в исключающем отношении к родительской сущности, указывают на то, что только одна из равноправных сущностей содержит экземпляр для любого из экземпляров родительской сущности. Исключающая характеристическая сущность представляет отношение «является» (is a).

На рисунке 14 представлена сущность КОНТЕЙНЕР и характеристические сущности РОЖОК и СТАКАНЧИК. Магазин мороженого, судя по всему, торгует не на развес, а отдельными порциями. Обратите внимание, что экземпляр КОНТЕЙНЕРА должен быть РОЖКОМ или СТАКАНЧИКОМ. КОНТЕЙНЕР не может быть одновременно и РОЖКОМ и СТАКАНЧИКОМ. Это исключающие характеристические сущности.

Сущность ПЕРСОНА на рисунке 14 имеет две характеристические сущности СОТРУДНИК и КЛИЕНТ. Заметьте, что исключающие характеристические сущности не позволят одному экземпляру ПЕРСОНЫ содержать факты, общие для СОТРУДНИКА и КЛИЕНТА. Естественно, это противоречит реальной практике. СОТРУДНИК определенно может быть КЛИЕНТОМ. ПОСТАВЩИК тоже может выступать в качестве КЛИЕНТА. Это пример включающих характеристических сущностей.

Рис. 14. Примеры характеристических сущностей ПЕРСОНА и КОНТЕЙНЕР.

Оба примера используют нотацию ERwin IE для представления исключающих и включающих характеристических сущностей. Отсутствие (X) в символе характеристической сущности указывает на включающее отношение.

Структурная сущность

Иногда экземпляры одной и той же сущности связаны. В своей книге 1992-го года «Strategic Systems Development» К. Финклештейн предложил использовать структурные сущности для представления отношений между экземплярами одной и той же сущности. Связи между экземплярами одной и той же сущности называются рекурсивными отношениями. Рекурсивные отношения – это логическая концепция, а концепции не легко воспринимаются пользователями.

На рисунке 15 показана дополнительная структурная сущность, описывающая отношение между экземплярами сущности СОТРУДНИК. Диаграмма показывает, что характеристическая сущность СОТРУДНИК сущности ПЕРСОНА имеет две характеристические сущности ИСПОЛНИТЕЛЬ и УПРАВЛЕНЕЦ. Сущность СТРУКТУРА СОТРУДНИКОВ представляет отношение между экземплярами сущности СОТРУДНИК.

Рис. 15. Структурная сущность – иллюстрация подхода К. Финклештейна к разрешению рекурсивных отношений.

Определение первичного ключа

Для идентификации конкретного экземпляра сущности вам необходимо определить первичный ключ. Первичным ключом служит атрибут или набор атрибутов, уникально идентифицирующих единственный экземпляр сущности. Другими словами, первичный ключ может быть как одним атрибутом, так и состоять из нескольких. Первичный ключ, состоящий более чем из одного атрибута, называется составным или компонентным ключом. Далее мы будем использовать термин составной ключ.

Первичный ключ должен быть статическим (static) и неразрушаемым (non-volatile). Под статичностью и неразрушаемостью подразумевается, что первичный ключ не должен подвергаться изменениям. Изменения первичного ключа трудно сопровождать, что часто приводит к весьма дорогостоящим переделкам, поэтому лучшим считается вариант, когда первичный ключ абсолютно не зависит от экземпляров сущности.

Далее будут добавлены первичные ключи в базу данных торговли мороженым и рассмотрены кандидаты в ключи.

Для нахождения первичного ключа требуется проанализировать данные, определяющие сущность. Как правило, первичные ключи для стержневых сущностей определяются во время рабочих сессий и обсуждений. Эксперты предметной области и пользователи – хорошие источники информации для выбора потенциальных первичных ключей. Примеры данных тоже обеспечивают ценный вклад при выборе первичного ключа.

Начинайте процесс выявления первичных ключей с определения всех потенциально ключевых атрибутов, называемых кандидатами в ключи. Кандидатом в ключи может быть и один атрибут, и комбинация нескольких атрибутов. Если кандидатов в ключи не существует, или кандидатом является составной ключ, который слишком велик и громоздок, рассмотрите возможность использования искусственного уникального идентификатора. Ключи, заимствованные из родительской сущности, называются внешними ключами. Ниже приведено описание различных типов ключей:

- Кандидат в ключи. Кандидатом в ключи является атрибут или набор атрибутов, идентифицирующих единичный экземпляр сущности. Иногда единичный экземпляр сущности идентифицируется несколькими атрибутами или их комбинацией.

- Составной ключ. Ключ, который состоит более чем из одного атрибута, называется составным, сложным или компонентным. Для составных ключей каждая составляющая ключа должна иметь значение для каждого экземпляра. Ни одна часть ключа не должна быть неопределенной (NULL). Все части ключа являются обязательными и не могут быть опущены.

- Искусственный первичный ключ. Иногда ни единичный атрибут, ни комбинация атрибутов, не определяют экземпляр. В этих случаях вы используете искусственный уникальный идентификатор. Искусственные первичные ключи часто просто нумеруют каждый экземпляр или код.

- Внешние ключи. Когда первичный ключ одной сущности мигрирует в другую таблицу, он называется внешним ключом. Внешние ключи «связывают» сущности, представляя отношения между ними.

Именование сущностей

Имя, присваиваемое сущности, должно характеризовать экземпляры сущности. Имя должно быть понятным и общепринятым. При выборе имени руководствуйтесь корпоративной точкой зрения и старайтесь использовать имена, отражающие способ использования данных в рамках корпорации, а не в отдельном подразделении. Используйте имена, осмысленные для сообщества пользователей и экспертов предметной области.

Соглашения об именовании сущностей

Соглашения об именовании могут показаться несущественными, если вы работаете в маленькой организации, с небольшим количеством пользователей. Однако, в большой организации с несколькими командами разработчиков и большим количеством пользователей, соглашения об именовании существенно помогают при взаимодействии и совместном использовании данных. В идеале, вы централизованно должны разработать и сопровождать соглашения об именовании, и затем документально оформить их, опубликовав для всей корпорации.

Ниже приведены некоторые положения для формирования начального набора соглашений об именовании, на случай, если в вашей организации пока такой набор не разработан:

- Имя сущности должно быть достаточно описательным. Используйте имена из одного слова, только когда они являются названием широко распространенных концепций. Подумайте об использовании словосочетаний на основе существительных.

- Имя сущности должно быть существительным или словосочетанием на основе существительного в единственном числе. Используйте ПЕРСОНА вместо ПЕРСОНЫ или ЛЮДИ, и КОНТЕЙНЕР – вместо КОНТЕЙНЕРЫ.

- Имя сущности должно быть уникальным. Использование одинаковых имен для сущностей, содержащих различные данные, или разных имен для сущностей, содержащих одинаковые данные, будет без необходимости вводить в заблуждение разработчиков и конечных пользователей.

- Имя сущности должно указывать на данные, которые будут храниться в каждом из экземпляров.

- Имя сущности не должно содержать специальных символов (таких как !, @, #, $, %, &, * и тому подобных) или указывать на принадлежность (МОРОЖЕНОЕ ПЕРСОНЫ).

- Имя сущности не должно содержать акронимов или аббревиатур, если только они не являются частью принятых соглашений об именовании.

Разработчикам моделей рекомендуется использовать хорошие соглашения об именовании, если таковые существуют, или разработать их, следуя приведенным положениям, если таких соглашений нет.

Примеры хороших имен сущностей

Всегда лучше использовать единообразные имена в рамках корпорации. В таблице 3 приведены примеры хороших и плохих имен для сущностей.

Для имен сущностей используются заглавные буквы, что соответствует рекомендуемому соглашению об именовании сущностей.

Таблица 3. Примеры имен сущностей с объяснениями.

Хорошее имя	Неудачное имя	Пояснение
МАТЕМАТИЧЕСКАЯ ФОРМУЛА	ФОРМУЛА	ФОРМУЛА – слишком расплывчато, добавление прилагательного МАТЕМАТИЧЕСКАЯ значительно проясняет смысл.
КНИГА	КНИГИ	КНИГА – существительное в единственном числе.
СОФА	СОФА КУШЕТКА	СОФА и КУШЕТКА имеют одинаковый смысл. Выберите что-то одно.
МОРОЖЕНОЕ	КАКОЕ-ТО МОРОЖЕНОЕ	Местоимение КАКОЕ-ТО не привносит дополнительного значения или смысла к термину. Избегайте излишних дополнений.
ФОТОСНИМОК	ИЗОБРАЖЕНИЕ	ФОТОСНИМОК – достаточно определенно. ИЗОБРАЖЕНИЕ - несколько расплывчато.
ОЖИДАЕМОЕ ВРЕМЯ ПРИБЫТИЯ	ОВП	Аббревиатура ОВП может оказаться непонятной для пользователей.
КОМПАНИЯ	КОМПАНИЯ XYZ	XYZ – конкретный экземпляр компании и должен быть строкой в сущности КОМПАНИЯ.

Описание сущностей

Даже хороших имен, указывающих пользователю, какую информацию стоит ожидать от сущности, обычно недостаточно. Каждая сущность нуждается в ясном, точном и полном описании или определении, чтобы быть однозначно интерпретируемой в рамках корпорации. Описание сущности должно объяснять смысл сущности и ее значение для корпорации.

Хотя описание, определение и назначение часто используются в качестве синонимов, термин описание предпочтительнее, поскольку он побуждает нас описывать сущности в терминах, понятных для пользователя.

Правила формирования хороших описаний

Описание сущности должно объяснять ее смысл, а не то, как будет использоваться информация этой сущности. Вы должны собирать описания сущностей во время идентификации сущностей. Будьте осторожны при включении информации об использовании: подобная информация должна использоваться только в качестве примера или для пояснения. Способ использования информации изменяется более часто, чем информация сама по себе, поэтому информация об использовании непостоянна.

Описание сущности должно быть ясным, точным, полным и непротиворечивым. Оно должно быть сформулировано без привлечения технических терминов, понятно любому, кто хотя бы чуть-чуть знаком с описываемой концепцией. Убедитесь, что описание сформулировано в терминах бизнеса, и включает пояснение значимости сущности.

Примеры хороших описаний

Таблица 4 служит для демонстрации хороших описаний и причин, по которым неудачные описания не отвечают основным положениям.

Таблица 4. Описания сущностей с пояснениями

Хорошее описание	Неудачное описание	Пояснение
ПЕРСОНА содержит информацию о физических лицах, которые вступают во взаимодействие с корпорацией. Информация о ПЕРСОНЕ помогает корпорации при планировании, разработке продуктов и рекламной деятельности.	Клиент или сотрудник.	Хорошее описание включает определение сущности и ее значение для корпорации.
	Включает имя, дату рождения и т.п. для персоны.	Простое перечисление атрибутов сущности не несет дополнительной информации о том, что собой представляет сущность и почему она важна для корпорации.
	Информация о клиентах и сотрудниках.	Клиент и сотрудник являются примерами ролей, в которых может выступать ПЕРСОНА. Использование одних только примеров не объясняет, что сущность собой представляет и почему она важна для корпорации.
	Сущность содержит символы и числовые данные, извлеченные из POS (Point Of Sale - торговый терминал), хранящиеся с использованием стандартного сжатия и упакованных десятичных чисел.	Данный искусственный пример призван проиллюстрировать, что технические описания и аббревиатуры с трудом понимаются бизнес-пользователями.

Распространенные ошибки при моделировании сущностей и выборе ключей

Иногда при моделировании разработчик модели делает некий выбор, руководствуясь совершенно правильными принципами. Очень важно понимать всю причинно-следственную цепочку принимаемых решений так, чтобы вы ясно понимали полученное заключение.

Моделирование ролей

Что подразумевается под моделированием ролей? Во время рабочих сессий пользователи могут сказать вам, что им необходимо хранить информацию о сотрудниках. Возникает искушение создать сущность СОТРУДНИК. Более тщательный анализ информации, представляющей интерес для корпорации, например, такой как имя, адрес и номер социального страхования показывает, что эти значения не зависят от сущности СОТРУДНИК. Для конкретного СОТРУДНИКА значение атрибута ИМЯ не зависит от сущности СОТРУДНИК. Это легко понять, если задуматься о том, что ваше имя остается вашим именем вне зависимости от того, являетесь ли вы СОТРУДНИКОМ или нет.

Перегрузка сущностей

Перегруженными являются сущности, содержащие информацию более чем об одном концептуальном объекте. Если некоторые атрибуты сущности описывают одну и ту же концепцию, такие сущности следует проверить. Перегруженные сущности имеют значения не для каждого из атрибутов.

Иногда эксперты из разных предметных областей в корпорации используют имя сущности, которое звучит и пишется одинаково, но имеет разный смысл для разных экспертов. Единственный способ убедится, что одинаковые имена описывают одинаковые объекты, это проверка описаний. Убедитесь, что сущность содержит данные, описывающие единственную концепцию.

Например, сущность ОБОРУДОВАНИЕ может иметь совершенно разное значение для подразделений информационных технологий и для отдела средств массовой информации и коммуникаций.

Избыточные сущности

Избыточными являются сущности, имеющие различные имена, но содержащие информацию о сходных концепциях. Английский язык включает много слов для представления одних и тех же вещей. Один из способов обнаружить такие сущности - это поиск сущностей, содержащих сходные атрибуты. Сравните описания каждой из таких сущностей, чтобы определить, не представляют ли они сходные концепции. Избыточные сущности часто появляются в результате тенденции к моделированию ролей в качестве сущностей.

Например, сущности УПРАВЛЕНЕЦ и СОТРУДНИК могут содержать сходную информацию, поскольку обе являются ролями, которые может играть экземпляр сущности ПЕРСОНА.

Выбор неправильного первичного ключа

Выбор неправильного первичного ключа означает, что вы выбрали первичный ключ, не выдерживающий тестирования. Распространенными ошибками, связанными с первичным ключом, являются:

- Не уникальность: первичный ключ не является уникальным для каждого из экземпляров. Например, разработчик модели может считать, что номер социального страхования является уникальным для каждой ПЕРСОНЫ. Однако номер социального страхования может повторно использоваться в том случае, если первоначальный его владелец скончался.

- Требуемое значение/неопределенность: первичный ключ не имеет значения для некоторых из экземпляров. Например, не каждый экземпляр сущности ПЕРСОНА будет иметь номер социального страхования. Иностранцы и маленькие дети – вот две категории людей, у которых он будет отсутствовать.

- Использование неудачных имен сущностей.

Непонятные, неоднозначные или неточные имена затрудняют для новых пользователей и команд разработчиков повторное использование или расширение существующей модели.

Не используйте аббревиатуры или акронимы в качестве части имени. Аббревиатуры и акронимы открыты для неправильной интерпретации и даже могут иметь разное значение в разных предметных областях.

Не используйте имена собственные, указывающие на конкретный экземпляр, такие как, например, Компания Интерфейс. Это неудачный выбор имени сущности, который в дальнейшем приведет к серьезным проблемам при моделировании.

Не включайте месторасположение в качестве части имени. Как правило, вам неизбежно потребуется и другое месторасположение. Имя с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса сущностей.

Использование неудачных описаний сущностей

Не используйте описаний, заимствованных только из словаря. Описания из словаря не будут включать значимую для бизнеса информацию.

Не пытайтесь перефразировать имя сущности. Не используйте имя сущности в ее описании.

Неясные, расплывчатые или, что еще хуже, неполные описания затрудняют повторное использование и расширение существующей модели. Пользователь не сможет проверить, содержит ли сущность всю необходимую информацию. При этом значительно повышается риск возникновения перегруженных сущностей и использования их для хранения информации о разных объектах.

Концепции, которые кажутся очевидными для всех участников рабочих сессий, могут перестать быть столь очевидными с течением времени, когда перед новой командой разработчиков будет поставлена задача расширения существующей модели.

Понятие атрибута

Рассмотрим процесс выявления атрибутов и их характеристик, определения ключевых и не ключевых атрибутов, областей определения и необязательных данных, а также сформулированы соглашения для формирования хороших имен и описаний атрибутов.

Ключевые атрибуты

Ключевыми являются атрибуты, значения которых определяют значения других атрибутов. Значения ключевых атрибутов не зависят от значений никаких других атрибутов. Ключ может состоять из единственного атрибута или быть составлен из нескольких атрибутов. Эти атрибуты могут быть первичными ключами, составными первичными ключами, кандидатами в ключи, внешними ключами или альтернативными ключами.

Атрибуты первичного ключа

Является ли первичный ключ единственным атрибутом или группой, его значения определяют значения всех других атрибутов.

Хороший первичный ключ будет обладать следующими признаками:

- значение гарантирует уникальность для каждого из экземпляров;

- значение не имеет скрытого смысла;

- область определения значений будет оставаться постоянной с течением времени;

- значения существуют для каждого из экземпляров сущности.

Искусственные первичные ключи

Искусственные первичные ключи – это атрибуты, созданные с единственной целью идентификации конкретных экземпляров сущности. В некоторых случаях не существует атрибута или группы, однозначно идентифицирующих экземпляр сущности. В других случаях, составной первичный ключ слишком громоздок, и его трудно сопровождать. Искусственный первичный ключ иногда называют псевдоключом или ключом, сгенерированным системой. Еще он известен под названием искусственный уникальный идентификатор, которое указывает на его назначение.

Искусственный первичный ключ часто формируется простой последовательной нумерацией каждого из экземпляров сущности. Дополнительным преимуществом таких искусственных ключей является то, что не нужно заботиться о смысле связанных с ними экземпляров сущности, кроме гарантии уникальности. Фактически, искусственные первичные ключи, созданные таким способом, гарантированно обладают особенностями хороших первичных ключей.

Обратите внимание, что большинство первичных ключей на Рисунке 3.5 являются искусственными. По большей части, первичный ключ является просто уникальным номером для каждого из экземпляров.

Кандидаты в ключи

Кандидатом в ключи является атрибут или группа атрибутов, идентифицирующих конкретный экземпляр сущности. Кандидат в ключи представляет механизм определения потенциальных первичных ключей для идентификации конкретных экземпляров сущности.

Кандидат в ключи, который не выбран в качестве первичного ключа, еще называют альтернативным ключом. Альтернативный ключ – это атрибут или группа атрибутов, которые могут быть использованы при индексировании.

Внешние ключи

Внешним ключом является атрибут или группа атрибутов, составляющих первичный ключ другой сущности. Внешний ключ может быть, а может и не быть, ключевым атрибутом в связанной сущности. Обратите внимание на термин связанная сущность. Внешние ключи представляют связи между сущностями.

Миграция атрибутов первичного ключа

Внешние ключевые атрибуты являются атрибутами первичного ключа другой сущности, которые мигрировали в данную сущность через связь. Внешние ключи могут быть как идентифицирующими, так и неидентифицирующими. Идентифицирующие внешние ключи становятся частью первичного ключа в той сущности, в которую они мигрировали. Неидентифицирующие внешние ключи становятся не ключевыми атрибутами.

Неключевые атрибуты

Неключевыми являются атрибуты, значения которых зависят от значений первичного ключа или составного первичного ключа. Эти не ключевые атрибуты должны зависеть от значения ключа, полного ключа, и ни от чего кроме ключа.

В своей книге «Strategic Systems Development» К. Финклештейн определяет несколько типов неключевых атрибутов:

- Селективные атрибуты – атрибуты, используемые для идентификации единственного экземпляра сущности, когда ключ не уникален. Также называются вторичными ключами.

- Групповой атрибут – атрибут, объединяющий группу более детальных атрибутов.

- Атрибуты повторяющейся группы – атрибуты, представляющие несколько включений одного атрибута в рамках сущности.

- Производные атрибуты – атрибуты, чьи значения определяются из значений других атрибутов.

- Атрибуты основных данных – атрибуты, которые не являются селективными, групповыми, атрибутами повторяющейся группы или производными.

Селективные, групповые и атрибуты повторяющейся группы не должны присутствовать в логической модели, приведенной к третьей нормальной форме. Селективные атрибуты должны стать частью первичного ключа, если они нужны для идентификации единственного экземпляра сущности. Групповые атрибуты являются многозначными. По моему мнению, групповые атрибуты лучше всего представлять в модели кодовыми или классификационными сущностями. Как отмечалось выше, повторяющиеся группы должны быть вынесены в подчиненные сущности.

В третьей нормальной форме не ключевые атрибуты должны быть простыми (основными) или производными атрибутами.

Простые атрибуты

Простые атрибуты – это атрибуты, которые в результате декомпозиции были доведены до наивысшей степени детализации и, таким образом, их значения полностью зависят от первичного ключа и определены для каждого из экземпляров сущности. Они не являются критерием выбора и не могут служить для группировки сущностей. Они представляют простые атомарные факты, в которых заинтересована корпорация.

Производные атрибуты

Производными атрибутами являются атрибуты, значения которых выведены или вычислены на основе значений одного или более других атрибутов. Вопрос допустимости присутствия производных атрибутов в логической модели активно обсуждается. Некоторые эксперты считают, что поскольку значения производных атрибутов зависят от значений исходных атрибутов, производные атрибуты не должны быть представлены в логической модели.

Логическая модель предназначена для полного и точного представления требований к информации. Вы можете принять решение создать производные атрибуты на уровне физической модели в соответствие с требованиями к использованию.

Хотя понятны аргументы в пользу исключения производных атрибутов, тем не менее, логическая модель – наилучшее место для введения имен и описаний всех атрибутов. Поэтому предпочтительнее включать производные атрибуты в логическую модель. Однако, разработчикам моделей стоит отказаться от использования производных атрибутов в качестве первичных ключей или части составных первичных ключей. Также не забудьте включить правило вывода в описание производного атрибута.

Нахождение области определения атрибута

Область определения атрибута задает список разрешенных значений, которые атрибут может принимать в конкретном экземпляре сущности. Область определения включает, по меньшей мере, область определения универсального типа данных и может включать область определения, заданную пользователем. В завершенной логической модели вы должны найти область определения для каждого из атрибутов.

Можно сказать, что область определения атрибута должна содержать, как минимум, два значения. Атрибут, для которого всегда разрешено только одно значение, вероятно, некорректно отображен в модели

В сущности БАНАНОВЫЙ ДЕСЕРТ присутствует атрибут Банан. Бизнес-правило утверждает, что каждый экземпляр сущности БАНАНОВЫЙ ДЕСЕРТ содержит банан. Поэтому у атрибута Банан может быть только одно значение и, вероятно, этот атрибут не является необходимым. Вместо этого описание сущности БАНАНОВЫЙ ДЕСЕРТ должно быть указание на то, что банан включается в каждый ее экземпляр. То же самое касается атрибута Помадка в сущности СЛИВОЧНАЯ ПОМАДКА.

В Таблице 5 приведены области определения логических типов данных сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ логической модели СМЕСЬ.

Таблица 5. Примеры логических типов данных.

Имя атрибута	Логический тип данных
Идентификатор специального предложения	Number (число)
Идентификатор мороженого	Number (число)
Идентификатор вкуса	Number (число)
Начало специального предложения	Date (дата)
Конец специального предложения	Date (дата)

Области определения простых и расширенных типов данных

Область определения типа данных определяет способ представления значений атрибута. В завершенной логической модели область определения типа данных требуется для каждого атрибута. В следующем списке приведено несколько примеров логических типов данных ERwin:

- Datetime – дата/время;

- Number – число;

- String – строка.

Многие из новых платформ баз данных поддерживают более развитые типы данных. Однако важно помнить, что эти сложные типы данных, за некоторым исключением, зависят от платформы. В любом случае, если пользователю нужен атрибут, он должен быть включен в модель, вне зависимости от его типа данных. Некоторые широко используемые расширенные типы данных приведены ниже:

- Image – изображение;

- Sound – звук;

- Video – видео.

Области определения, вводимые пользователем

Области определения, вводимые пользователем – специализированные области определения, которые уточняют набор значений, допустимых для атрибута. Эти области определения часто специфичны для организации и должны определяться и использоваться единообразно в пределах корпорации. Например, атрибут с областью определения типа данных Number может, кроме того, иметь введенную пользователем область определения, которая ограничивает возможные значения пределами от 1 до 100. Принцип целостности дает корпорации возможность внести изменения в одной сущности расширить область определения для каждого из атрибутов, который ее использует.

Определение необязательности атрибута

Значение атрибута может быть обязательным или нет. Если значение требуется, или обязательно, значение должно присутствовать в момент создания экземпляра. Если значение необязательно, вы можете создавать экземпляры без него.

В книге «Information Engineering: Strategic Systems Development» К. Финклештейн определяет свойство обязательности атрибута через серию правил «редактирования»:

- добавляется сразу, изменить позже – нельзя;

- добавляется сразу, изменяется позже;

- добавляется позже, изменяется позже;

- добавляется позже, изменить потом – нельзя.

Внимательно следите за необязательными атрибутами. Если атрибут или набор атрибутов имеет значение только для конкретных экземпляров сущности, рассмотрите возможность его переноса в сущность, где значение будет существовать для каждого из экземпляров.

В Таблице 6 указано свойство обязательности для атрибутов сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ. Обратите внимание на тот факт, что при создании экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ значения требуются для всех атрибутов кроме атрибута Дата окончания специального предложения.

Таблица 6. Примеры обязательности атрибутов

Имя атрибута	Обязательность
Идентификатор специального предложения	Требуется
Идентификатор мороженого	Требуется
Идентификатор вкуса	Требуется
Начало специального предложения	Требуется
Конец специального предложения	Необязательно

В Табл. 6 представлено бизнес-правило, которое говорит, что для экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ требуется следующая информация:

- идентификатор сущности (Идентификатор специального предложения);

- идентификатор вкусовой добавки специального предложения (Идентификатор мороженого и Идентификатор вкуса);

- дата начала специального предложения (Начало специального предложения)

Дата окончания для каждого экземпляра сущности СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ необязательна. Бизнес-правило утверждает, что СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ должно иметь начало, но не обязательно должно иметь конец.

Атрибуты, значения которых обязательны, не могут иметь пустых значений. Некоторые эксперты считают, что значение должно быть обязательным для каждого экземпляра сущности. Естественно, в предположении, что значение каждого атрибута экземпляра сущности найдено или известно, до того, как экземпляр создается.

Атрибуты, чьи значения необязательны, могут иметь пустые значения. Некоторые эксперты считают, что атрибут не должен присутствовать в сущности, если его значение недоступно для каждого из ее экземпляров. Одной из причин является сложность интерпретации пустых значений. Означает ли пустое значение, что это значение неизвестно для экземпляра, или оно просто не было получено?

Среди разработчиков моделей дискуссия о недостатках и достоинствах требуемых и необязательных значений все еще продолжается. Одни разработчики уверены, что атрибут не должен иметь пустых значений, и утверждают, что область определения должна содержать такие значения, как неизвестен и неполучен. Другие считают обязательность значений, и использование области определения также требует и использования значений по умолчанию, что приводит к ненадежным сомнительным значениям.

Предпочтительнее использовать пустые значения и переложить ответственность за работу с пустыми значениями на прикладную программу или средство формирования запросов. Это наиболее адекватное и гибкое решение, поскольку оно позволяет интерпретировать пустые значения по-разному для удовлетворения разных требований бизнеса.

Именование атрибутов

Каждый атрибут должен иметь ясное, точное и непротиворечивое имя. Имя атрибута не должно конфликтовать с его описанием. Имя атрибута должно указывать на значения, собираемые для экземпляров атрибута. Имя атрибута должно быть понятным и общепринятым в корпорации.

При выборе имени для атрибута, сохраняйте точку зрения корпорации и позаботьтесь о том, чтобы оно отражало смысл атрибута, а не то, как он будет использоваться. Используйте имена, осмысленные для сообщества пользователей и экспертов предметной области.

Вероятно, что у вас в корпорации есть набор соглашений об именовании атрибутов, разработанные в вашей корпорации или при формировании корпоративной модели данных, которыми вы руководствуетесь. Использование соглашений именования атрибутов гарантирует, что имена конструируются единообразно в рамках корпорации, вне зависимости от того, кто конструирует имя.

Соглашения об именовании атрибутов важны, вне зависимости от того, в маленькой или большой организации вы работаете. Однако, в большой организации с несколькими командами разработчиков и большим количеством пользователей, соглашения об именовании существенно помогают при взаимодействии и понимании элементарных данных. В идеале, вы должны разработать и сопровождать соглашения об именовании атрибутов централизованно и затем документально оформить и опубликовать их для всей корпорации.

Ниже представлены некоторые положения для формирования начального набора соглашений об именовании атрибутов, просто на случай, если в вашей организации пока такой набор не разработан:

- Имя атрибута должно быть достаточно описательным. Подумайте об использовании словосочетаний на основе существительных в форме объект/модификатор/класс.

- По возможности имя атрибута должно включать имя сущности. Используйте «Имя для персоны» вместо просто «Имя».

- Имя атрибута должно указывать на значения конкретных экземпляров атрибута. Использование одинаковых имен для атрибутов, содержащих различные данные, или разных имен для атрибутов, содержащих одинаковые данные, будет без необходимости вводить в заблуждение разработчиков и конечных пользователей.

- Имя атрибута должно использовать язык бизнеса вместо языка технических описаний.

- Имя атрибута не должно содержать специальных символов (таких как !, @, #, $, %, ^, &, * и тому подобных) или указывать на принадлежность (Имя, принадлежащее персоне).

- Имя атрибута не должно содержать акронимов или аббревиатур, если только они не являются частью принятых соглашений именования.

Разработчикам моделей предпочтительно использовать хорошие соглашения именования, если таковые существуют, или разработать их, если таких соглашений нет.

Имена атрибутов в форме Объект/Модификатор/Класс

Форма объект/модификатор/класс – широко распространенное в отрасли соглашение об именовании атрибутов. Это соглашение побуждает использовать имена атрибутов, состоящие из трех частей. Часть объект иногда называют субъектом или основным словом. В качестве объекта обычно используется имя сущности.

Модификатор может быть одиночным термом или группой термов. Хотя списка стандартных модификаторов не существует, разработчикам моделей желательно формировать короткие осмысленные модификаторы. Использование модификаторов позволяет вам создавать наглядные осмысленные имена атрибутов. Если имя становится неприемлемо тяжеловесным для пользователей или широкого применения, как требуется в корпорации, вы можете пойти на компромисс, отказавшись от трехсложных имен атрибутов.

Базовой частью имени атрибута является класс, который определяет тип информации, представляемой атрибутом. Некоторые часто используемые классы:

- идентификатор,

- код,

- дата,

- число,

- величина,

- количество,

- частота.

Примеры имен атрибутов

В рамках корпорации всегда лучше использовать единообразные имена атрибутов. В Таблице7 приведены примеры хороших и плохих имен для атрибутов. Обратите внимание, что слова в имени атрибута отделены пробелами, начинаются с заглавных букв и используют строчные символы для остальных.

Таблица 7. Имена атрибутов с пояснениями

Хорошее Имя	Неудачное имя	Пояснение
Person First Name (Имя персоны)	Name (Имя)	Name (Имя) – название класса и нуждается в обозначении объекта Person (персона) и в модификаторе First (первое).
Ice Cream Sales Quantity (Объем продаж мороженого)	The Quantity of Sales (Объем продаж)	Quantity (Количество) – название класса и должно быть на последнем месте (в английском варианте имени атрибута). "The" и "of" не привносят дополнительного смысла.
Item Cost Amount (Величина стоимости позиции)	Cost of Item (Стоимость позиции)	"of" не привносит дополнительного смысла. Название класса "Amount" (величина) указывает пользователю, что должно быть в атрибуте.
Product Identifier (Идентификатор продукта)	Product Identifiers (Идентификаторы продуктов)	"Identifiers" (Идентификаторы) – множественное число. Имя атрибута должно быть существительным в единственном числе.
Point of Sale Location Code (Код местоположения точки продаж)	POS Code (Код POS)	"POS" – аббревиатура. Использованное название класса "Code" (код) нуждается в модификаторе.
Person Birth Date (Дата рождения персоны)	Birthday (День рождения)	Birthday (День рождения) не содержит названия класса Date (Дата). Включение модификатора и имени объекта проясняет смысл имени атрибута.

Описание атрибутов

Описание атрибута должно быть коротким пояснением смысла атрибута, а не того, как он используется. Описание атрибута не должно противоречить его имени и не должно быть простым повторением имени. Используйте название класса и объекта в утверждении для точного описания данных. Если атрибут выводится или рассчитывается, включайте правила вывода или формулы расчета.

Следующие правила касаются описания атрибутов:

- описание атрибута должно быть ясным, полным и однозначным;

- описание атрибута должно соответствовать его имени;

- описание атрибута не должно опираться на описание другого атрибута;

- описание атрибута должно формулироваться на языке бизнеса, а не на языке технических описаний;

- имя атрибута должно отражать его смысл, а не то, как он используется;

- в описании атрибута должны быть расшифрованы все аббревиатуры и акронимы, использованные в его имени;

Разработчикам моделей рекомендуется давать хорошие описания для каждого из атрибутов. Хорошие описания атрибутов делают легким использование модели для всех. Те, кто использует модель, созданную хорошим разработчиком, испытывают удовольствие от хорошо сформулированных в модели требований к информации. Сравните примеры из таблицы 8.

Таблица 8. Имена и описания атрибутов с пояснениями.

Имя атрибута	Хорошее описание	Неудачное описание	Пояснение
Person First Name (Имяперсоны)	Имя персоны, которое позволяет корпорации общаться с персоной, используя дружеские обращения.	Поле с длиной в 40 символов.	Не используется язык бизнеса. Применены технические термины.
Ice Cream Sales Quantity (Объем продаж мороженого)	Количество мороженого конкретного сорта, проданного в рамках конкретного мероприятия по продаже.	Объем продаж.	Не добавляет нового смысла, а просто перефразирует имя атрибута в расплывчатых терминах.
Item Cost Amount (Величина стоимости позиции)	Величина стоимости конкретной позиции в конкретный период времени. Представляет суммарную стоимость продажи и доставки.	Шестизначное десятичное число с двумя знаками после запятой.	Слишком техническое описание. Почти ничего не значит для пользователей элемента данных.
Product Identifier (Идентификатор продукта)	Искусственный уникальный числовой идентификатор для конкретного продукта.	Идентификаторы продуктов.	Простая перефразировка имени атрибута.
Point of Sale Location Code (Код местоположения точки продаж)	Уникальный код, идентифицирующий географическое положение точки продаж.	Код POS.	Использованный акроним может быть непонятен пользователям. Кроме того, в описании опущен важный модификатор.
Person Birth Date (Дата рождения персоны)	Дата рождения персоны.	День рождения персоны.	В описании опущено название класса “дата”.

Распространенные ошибки при работе с атрибутами

Этот раздел, посвященный распространенным ошибкам при моделировании атрибутов, не претендует на полноту. Цель его - указать на наиболее распространенные ошибки, которые встречаются у разработчиков моделей.

Иногда, при моделировании чего-либо определенным способом, разработчик модели делает сознательный выбор, руководствуясь вполне правильными принципами. Очень важно понимать всю причинно-следственную цепочку принимаемых решений и результаты, к которым они могут привести.

Моделирование в терминах значений

Что понимается под моделированием в терминах значений? Во время рабочей сессии пользователи могут сказать вам, что им нужен набор атрибутов, указывающих на возрастные категории экземпляра сущности ПЕРСОНА. В этом сценарии возникают, по меньшей мере, три проблемы:

- способ определения возрастных категорий в корпорации со временем может измениться;

- возраст конкретной персоны определенно меняется с течением времени;

- все атрибуты будут представлять значения атрибута Возраст персоны. Естественно, Возраст персоны с течением времени будет меняться, так что лучшим решением будет использование в модели простого атрибута Дата рождения персоны.

Если приобретенные или производные данные, такие как возрастная категория, это единственное, что доступно, тогда они, конечно, должны быть включены в модель. Если доступны и возрастная категория и дата рождения, включите в модель и категорию, и дату рождения, и выводите возрастную категорию из даты рождения для экземпляров, для которых дата рождения известна. Как часто придется делать вывод и будет ли возрастная категория иметь физическое представление, зависит от требований к использованию.

Моделирование многозначных атрибутов

Многозначными являются атрибуты, имеющие несколько значений для концепции. Проверьте описания атрибутов, которые указывают на наличие нескольких значений для одной и той же концепции.

Иногда эксперты из различных предметных областей в корпорации используют имя атрибута, которое пишется и произносится одинаково, но имеет разные значения для разных экспертов. Один из способов убедиться в том, что атрибуты с одинаковыми именами описывают одинаковые объекты, заключается в проверке описаний. Убедитесь, что значения атрибутов описывают единственную концепцию.

Например, вы можете создать искусственные коды путем соединения одного или нескольких кодов для связи прежде не связанных данных. Текстовые фрагменты могут скрывать множество ценных атрибутов и значений.

Неудачное разрешение многозначных атрибутов может привести к тому, что некоторые важные бизнес-правила останутся необнаруженными и недокументированными.

Моделирование избыточных атрибутов

Избыточными являются атрибуты с разными именами, но содержащие информацию о сходных концепциях. Во всех языках существует много слов, представляющих одни и те же вещи. Один из способов найти избыточные атрибуты – просмотреть сущности с похожими атрибутами. Сравните описания всех атрибутов для проверки того, не содержат ли эти сущности данные о сходных концепциях. Избыточные атрибуты часто являются результатом тенденции к моделированию значений в качестве атрибутов. Например, сущности УПРАВЛЕНЕЦ и ИСПОЛНИТЕЛЬ могут содержать атрибуты Имя менеджера и Имя исполнителя. Так как и УПРАВЛЕНЕЦ, и ИСПОЛНИТЕЛЬ являются ролями, в которых может выступать экземпляр сущности ПЕРСОНА, вы можете переместить туда этот атрибут и назвать его Имя ПЕРСОНЫ.

Использование неудачных имен для атрибутов

Неясные, неоднозначные или неточные имена атрибутов усложняют для новых пользователей и команд разработчиков повторное использование или развитие существующей модели.

Не используйте аббревиатур или акронимов в качестве части имени атрибута. Аббревиатуры и акронимы открыты для неправильной интерпретации и даже могут иметь разное значение в разных предметных областях.

Не используйте имена собственные, указывающие на значение для конкретного экземпляра. Имя атрибута, использующее имя собственное - индикатор серьезных проблем при моделировании, заключающихся не только в неудачном выборе имени. Не включайте месторасположение в качестве части имени атрибута. Если значение существует для одного месторасположения, оно определенно существует и для другого месторасположения. Имя атрибута с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса.

Использование неудачных описаний для атрибутов

Не используйте описаний атрибутов, заимствованных только из словаря. Описания из словаря не будут включать информацию, значимую для бизнеса, которая делает атрибут важным для корпорации. Не используйте простое перефразирование имени атрибута. Не используйте имени атрибута в его описании.

Неясное, неопределенное описание атрибута, или что еще хуже - его отсутствие, затрудняет повторное использование или развитие существующей модели. Пользователи не смогут проверить, что модель содержит все требования к информации. Это так же повышает вероятность использования в модели вместо атрибутов конкретных значений и многозначных атрибутов.

Отношения

Сущности и отношения служат для группировки связанных атрибутов. Рассмотрим роль отношений в процессе моделирования и свойства и типы отношений.

ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями [раздел 4.1.2: понятие сущности]. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

Неограниченное (обязательное) отношение представляет собой безусловное отношение, т.е. отношение, которое всегда существует до тех пор, пока существуют относящиеся к делу сущности.

Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями.

Существенно-ограниченное отношение используется, когда соответствующие сущности взаимозависимы в системе.

Связи

Для идентификации требований, в соответствии с которыми сущности [раздел 4.1.2: понятие сущности] вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Каждая связь должна именоваться глаголом или глагольной фразой.

ЗНАЧЕНИЕ связи характеризует ее тип и, как правило, выбирается из следующего множества: {«O или 1», «0 или более», «1», «1 или более», «p:q» ( диапазон )}.

Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:

1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

- 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.

- n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).

4.2. Диаграммы «СУЩНОСТЬ-СВЯЗЬ»

Диаграммы «сущность-связь» (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).

Данная нотация была введена Ченом [7] (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD, а также диаграммы атрибутов и диаграммы декомпозиции. Эти диаграммные техники используются прежде всего для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования как иерархических, так и сетевых баз данных).

Разработка ERD включает следующие основные этапы:

- идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей;

- идентификация отношений между сущностями и указание типов отношений;

- разрешение неспецифических отношений (отношений n*m).

4.2.1. Сущности, отношения и связи в нотации Чена.

Символы ERD, соответствующие сущностям и отношениям, приведены на рисунке 16.

Рис. 16. Символы ERD в нотации Чена

На рисунке 17 приведена диаграмма «сущность-связь», демонстрирующая отношения между объектами банковской системы. Согласно этой диаграмме каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ ровно один зависимый от нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ.

Рис 17. ER-диаграмма в нотации Чена

4.2.2. Диаграммы атрибутов

Каждая сущность [раздел 4.1.2: понятие сущности] обладает одним или несколькими атрибутами [раздел 4.1.2: понятие атрибута], которые однозначно идентифицируют каждый экземпляр сущности. При этом любой атрибут может быть определен как ключевой.

Детализация сущности осуществляется с использованием диаграмм атрибутов, которые раскрывают ассоциированные с сущностью атрибуты. Диаграмма атрибутов состоит из детализируемой сущности, соответствующих атрибутов и доменов, описывающих области значений атрибутов. На диаграмме каждый атрибут представляется в виде связи между сущностью и соответствующим доменом, являющимся графическим представлением множества возможных значений атрибута. Все атрибутные связи имеют значения на своем окончании. Для идентификации ключевого атрибута используется подчеркивание имени атрибута.

Пример диаграммы атрибутов, детализирующей сущность КРЕДИТНАЯ КАРТА (см. рис.16) приведен на рисунке 18.

Рис. 18. Диаграмма атрибутов.

4.2.3. Категоризация сущностей

Сущность может быть разделена и представлена в виде двух или более сущностей-категорий, каждая из которых имеет общие атрибуты и/или отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем. Сущности-категории могут иметь и свои собственные атрибуты и/или отношения, а также, в свою очередь, могут быть декомпозированы своими сущностями-категориями на следующем уровне. Расщепляемая на категории сущность получила название общей сущности (отметим, что на промежуточных уровнях декомпозиции одна и та же сущность может быть как общей сущностью, так и сущностью-категорией).

Для демонстрации декомпозиции сущности на категории используются диаграммы категоризации. Такая диаграмма содержит общую сущность, две и более сущности-категории и специальный узел-дискриминатор, который описывает способы декомпозиции сущностей (см. рис.19).

Рис.19. Диаграмма категоризации

Существуют 4 возможных типа дискриминатора (рис.20):

- Полное и обязательное вхождение E/M (exclusive/mandatory) – сущность должна быть одной и только одной из следуемых категорий. Для примера на рисунке 19 это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК.

- Полное и необязательное вхождение E/O (exclusive/optional) – сущность может быть одной и только одной из следуемых категорий. Это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК, или преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

- Неполное и обязательное вхождение I/M (inclusive/mandatory) – сущность должна быть по крайней мере одной из следуемых категорий. Это предполагает в дополнение к 1) задавать следующую ситуацию: ПРЕПОДАВАТЕЛЕМ является одновременно и ФИЗИК и ХИМИК.

- Неполное и необязательное вхождение I/O (inclusive/optional) – сущность может быть по крайней мере одной из следуемых категорий. ПРЕПОДАВАТЕЛЕМ является преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

Рис.20. Типы дискриминаторов.

4.2.4. Нотация Баркера

Дальнейшее развитие ER-подход получил в работах Баркера [8], предложившего оригинальную нотацию, которая позволила на верхнем уровне интегрировать предложенные Ченом средства описания моделей.

В нотации Баркера используется только один тип диаграмм – ERD. Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута).

Все связи [раздел 4.1.2: связи] являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи – в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной – пунктирная линия. На рисунке 21 приведен фрагмент ERD для банковской задачи в нотации Баркера.

Рис.21. Нотация Баркера

Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова «должен (быть)» или «может (быть)». Так, диаграмма, приведенная на рисунке 21, читается следующим образом: Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ или Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ.

В заключение отметим, что понятия категория и общая сущность заменяются Баркером на эквивалентные понятия подтипа и супертипа, соответственно.

4.3. Создание физической модели данных

4.3.1. Уровни физической модели

Различают два уровня физической модели:

- трансформационная модель (Transformation Model);

- модель СУБД (DBMS Model).

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Трансформационная модель содержит информацию для реализации отдельного проекта, который может быть частью общего ПО и описывать подмножество предметной области. ERwin поддерживает ведение отдельных проектов, позволяя проектировщику выделять подмножество модели в виде предметных областей (Subject Area). Трансформационная модель позволяет проектировщикам и администраторам БД лучше представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям к ПО.

Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.

4.3.2. Средства структурного проектирования

Проектирование – фаза ЖЦ, на которой вырабатывается, как реализуются требования пользователя, которые порождены и зафиксированы на фазе анализа. На этом этапе осуществляется построение модели реализации (или физической модели), демонстрирующей, как система будет удовлетворять предъявленным к ней требованиями (без технических подробностей). Модель реализации является расширением модели требований и состоит из взаимоувязанных диаграмм (DFD, STD, ERD, структурные карты), текстов и словаря данных. Фактически структурное проектирование является мостом между структурным анализом и реализацией.

Техника структурных карт (схем) используется на фазе проектирования для того, чтобы продемонстрировать, каким образом системные требования будут отражаться комбинацией программных структур. При этом наиболее часто применяются две техники:

- структурные карты Константайна (Constantine),

- предназначенные для описания отношений между модулями, и структурные карты Джексона (Jackson), предназначенные для описания внутренней структуры модулей.

Структурные карты Константайна

Базовыми строительными блоками программной системы являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, ниже перечисленные из которых существенны при структурном проектировании:

- модуль состоит из множества операторов языка программирования, записанных последовательно;

- модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту;

- модуль может принимать и/или передавать данные как параметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.

Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы. При этом циклические и условные вызовы модулей моделируются специальными узлами, поэтому потоки должны быть изображены проходящими через эти специальные узлы. Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам (т.е. к вызовам модулей), стрелками указываются направления потоков и связей. Фундаментальные элементы структурных карт в соответствии со стандартами IBM, ISO и ANSI приведены на рисунке 22.

Рис. 22. Элементы структурных карт

Базовым элементом структурной карты является модуль. Возможно, использовать различные типы модулей (см. рис. 23.):

- Собственно МОДУЛЬ. Используется для представления обрабатывающего фрагмента для его локализации на диаграмме.

- ПОДСИСТЕМА. Ранее определенный модуль, детализированный посредством декомпозиции ранее определенных диаграмм. Может повторно использоваться любое число раз на любых структурных картах.

- БИБЛИОТЕКА. Отличается от подсистемы тем, что определена вне проекта данной системы.

- ОБЛАСТЬ ДАННЫХ. Используется для указания модулей, содержащих исключительно области глобальных/распределенных данных.

Рис. 23. Типы модулей

При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использований потоков, демонстрирующих иерархию вызовов. Типы используемых при этом потоков приведены на рисунке 24. При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно (параллельно).

Рис. 24. Типы вызовов модулей

Для моделирования условных и циклических вызовов применяются следующие узлы (рис. 25):

Условный узел используется для условного вызова модуля-потомка. Он изображается с помощью ромба, потоки – альтернативные вызовы изображаются выходящими из него. Таким образом, если из ромба выходят два потока, это соответствует конструкции IF-THEN-ELSE, если один поток – конструкции IF-THEN.

Итерационный узел используется для того, чтобы показать, что модуль-наследник вызывается в цикле. Он изображается полуокружностью со стрелкой с выходящими из него потоками.

Рис. 25. Условные и циклические вызовы модулей

Если необходимо показать, что подчиненный модуль не вызывается повторно при активации главного, это осуществляется указанием цифры «1» в главном модуле напротив потока – вызова наследника.

Связи по данным и управлению между модулями (передаваемые как параметры) раскрываются аннотированием потоков-вызовов (рис. 26). Стрелками отмечаются направления связей.

Рис. 26. Связи по данным и управлению

Пример структурной карты, описывающей межмодульные отношения в рассмотренном ранее фрагменте банковской системы, приведен на рисунке 27.

Рис. 27. Пример структурной карты Константайна

Структурные карты Джексона

Техника структурных карт Джексона основана на методологии структурного программирования Джексона и заключается в продуцировании диаграмм (структурных карт) для графического иллюстрирования внутримодульных (а иногда и межмодульных) связей и документирования проекта архитектуры [раздел 1.2.3] системы ПО. При этом техника позволяет осуществлять проектирование нижнего уровня структуры ПО и на этом этапе является близкой к традиционным блок-схемам.

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

- СТРУКТУРНЫЙ блок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.

- ПРОЦЕДУРНЫЙ блок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.

- БИБЛИОТЕЧНЫЙ блок аналогичен процедурному и представляет вызов библиотечного модуля.

- для взаимоувязывания блоков используются связи следующих типов:

- последовательная связь, обеспечивающая последовательное выполнение слева направо;

- параллельная связь, обеспечивающая одновременное выполнение блоков;

- условная связь, обеспечивающая выбор одной из альтернатив;

- итерационная связь, обеспечивающая выполнение блока в цикле.

4.4. Объектно-ориентированный подход при проектировании

При проектировании сложной ИС она разбивается на части, каждая из которых затем рассматривается отдельно (декомпозиция). Возможны два различных способа декомпозиции ИС на подсистемы: структурное (функциональное) разбиение и объектная (компонентная) композиция. Суть функционального разбиения отражается известной формулой: «программа = данные + алгоритм». При функциональной декомпозиции программной системы, ее структура может быть описана блок-схемами, узлы которых являются «обрабатывающим центром», или функцией, а связи между узлами описывают движение данных.

При объектном разбиении используются следующий принцип декомпозиции: система разбивается на активные сущности, то есть объекты (компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг с другом в отношении клиент-сервер. Сообщения, которые может принимать объект, определяется в его интерфейсе. В этом смысле посылка сообщений объекту-серверу эквивалентен вызову соответствующего метода объекта, то есть, если при проектировании ИС система разбивается на объекты, то для его визуального проектирования может быть использован язык UML, и если используется функциональная декомпозиция, то надо использовать структурные методологии (IDEF [раздел 4.1.2]).

4.4.1. UML – язык моделирования и документирования сложных систем

Все современные средства программирования имеют библиотеки компонент, позволяющие использовать отлаженный программный код, что значительно облегчает сбор программных приложений. Это стало возможным за счет использования объектов. С точки зрения визуального моделирования UML можно охарактеризовать следующим образом: UML предоставляет средства для создания визуальных моделей, которые единообразно понимаются всеми разработчиками, вовлеченными в проект; являются средством коммуникации в рамках проекта.

Характерные признаки языка UML [5]:

- UML не зависти от объектно-ориентированных языков программирования;

- не зависит от использования от используемых методологий разработки проекта;

- может поддерживать любой объектно-ориентированный язык программирования;

- является открытым и обладает средствами расширения базового ядра.

Рис. 28. Схема представления модели при объектно-ориентированном анализе.

UML-диаграммы могут преобразовываться в исходный код (прямое преобразование) и наоборот исходный код может преобразовываться в диаграммы (обратное преобразование). В некоторых случаях прямое преобразование может осуществляться автоматически с помощью программ конверторов.

Документирование исходных кодов программ UML диаграммами и спецификациями создает единый язык общения между программистами, а также между программистами, системными аналитиками и заказчиками автоматизированной системы. Но самое главное, что дает использование UML – это возможность широкой стандартизации языков программирования. Известно, что в разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и символьные обозначения. Язык UML позволяет стандартизовать как сами операции и методы языков программирования, так и их терминологию.

4.4.2. Структура языка UML

Язык UML имеет сложную иерархическую структуру, показанную на рисунке 29.

Рис. 29. Структура языка UML

Как видно из рисунка 29, первый иерархический уровень языка UML составляют сущности, отношения между сущностями и наглядные диаграммы. Рассмотрим последовательно эти основные понятия языка UML.

Язык UML имеет четыре вида сущностей: структурные, поведенческие, группирующие и аннотационные сущности. Они показаны на втором уровне структурного дерева языка UML, представленного на Рис. 28.

Далее на третьем уровне дерева показано, что понятие «структурные сущности» является именем семи видов пиктограмм, которые называются классами, интерфейсами, кооперациями, прецедентами, активными классами, компонентами и узлами.

Поведенческие сущности делятся на два вида диаграмм. Диаграммы первого вида называются взаимодействиями, второго вида – автоматами. Группирующие сущности имеют только один вид пиктограмм, называемых пакетами. Аннотационные сущности также имеют один вид пиктограмм, называемых примечаниями.

На рисунке 30 в качестве примеров показаны пять видов пиктограмм – классы, прецеденты, актеры, пакеты и примечания.

Рис. 30. Изображения некоторых сущностей в UML

Класс изображается прямоугольником, разделенным на три поля. В первом поле помещается имя класса, однозначно определяющее данный класс среди множества других классов. Во втором поле помещаются атрибуты (общие свойства) класса. В третьем поле располагаются типовые операции, выполняемые объектами, принадлежащими данному классу. Таким образом, класс – это совокупность объектов с общими атрибутами и операциями, а также с общими отношениями и семантикой. Объектами, объединенными в класс, могут быть, например, люди, окна системы Windows, экранные кадры и другие реальные или абстрактные объекты. На рисунке 31 показаны пиктограммы, изображающие класс «окно» и класс «экранный кадр».

Рис. 31. Класс «Окно» и «Электронный кадр»

Детальная нотация класса дает возможность программистам и аналитикам визуализировать, специфицировать, конструировать и документировать класс на любом желаемом уровне детализации свойств класса, достаточном для поддержки прямого и обратного проектирования моделей и кода.

Прецедент – это описание множества последовательных событий, выполняемых компьютерной системой, которые приводят к наблюдаемому актером результату. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только имя прецедента.

Актер – это кто-то (или что-то) внешний по отношению к компьютерной системе, кто взаимодействует с ней. Графически актер изображается в виде пиктограммы, представляющей человека, поскольку актер это человек или группа людей, использующих данные, предоставляемые компьютерной системой. На UML диаграммах пиктограммы прецедента и актера обычно располагаются рядом. В совокупности они могут описывать внешнюю границу компьютерной системы.

Показанная на рисунке 30 пиктограмма «пакет» изображает единственную в языке UML первичную группирующую сущность. В пакет можно поместить структурные и поведенческие сущности, и даже другие пакеты. Изображается пакет в виде папки с закладкой. Существуют также вариации пакетов, например, каркасы, модели и подсистемы.

Последняя пиктограмма, показанная на рисунке 30, называется «примечание». Примечание изображается в виде прямоугольника с загнутым краем. На UML диаграмме примечание присоединяется к одному или нескольким элементам диаграммы. Внутри прямоугольника-примечания помещаются комментарии или ограничения, относящиеся к элементу (или нескольким элементам) диаграммы. Комментарий может быть текстовым или графическим.

Рассмотрим теперь пиктограммы отношений, используемых в UML- диаграммах. Отношения составляют вторую ветвь структурного дерева языка UML, представленного на рисунке 29. Однонаправленные отношения представляются на UML диаграммах стрелками различных видов, а двунаправленное отношение представляется линией (рис. 32).

Рис. 32. Отношения в UML

Отношение зависимость – это семантическое отношение между двумя сущностями, такое при котором изменение одной (первичной) сущности вызывает изменение семантики другой, зависимой сущности.

Ассоциация – это структурное двунаправленное отношение, описывающее совокупность взаимоотношений между объектами. По сути дела ассоциация является сверткой бинарных отношений между объектами. Эту свертку может мысленно выполнить в своем сознании специалист, который видит пиктограмму ассоциации на UML диаграмме.

Пометка единица (1) на левом конце линии ассоциации на рисунке 32 означает, что в двунаправленном отношении, наряду с многими работниками участвует один работодатель. Единица и звездочка на правом конце линии означает «единица или больше» (1..*). Если один конец линии ассоциации помечен единицей (1), то пометка на другом конце линий называется кратностью ассоциации. Кратность правого конца ассоциации, показанной на рисунке 32, равна единице или больше.

На линии ассоциации можно также задать кратность равную единице (1), можно указать диапазон кратности: ноль или единица (0..1), много (0..*). Разрешается также указывать кратность определенным числом (например, 5). С помощью списков можно задавать и более сложные кратности. Например, список 0..1, 3..4, 6..* означает «любое число объектов кроме 2 и 5».

Обобщение – это однонаправленное отношение, называемое «потомок/прародитель», в котором объект «потомок» может быть подставлен вместо объекта прародителя (родителя или предка). Потомок наследует структуру и поведение своего родителя. Стрелка всегда указывает на родителя.

Наконец, реализация – это семантическое однонаправленное отношение, которое может устанавливаться, во-первых, между интерфейсами и реализующими их классами или компонентами, во-вторых, между прецедентами и реализующими их кооперациями. Интерфейсы, компоненты и кооперации это еще три вида пиктограмм, относящихся к структурным сущностям (см. рис. 29). Пиктограммы интерфейса, кооперации и компонента показаны на рисунке 33.

Рис. 33. Виды реализаций

Интерфейс – это совокупность операций, предоставляемых классом или компонентом. Следовательно, интерфейс описывает поведение класса или компонента, видимое извне. Интерфейс определяет только описание (спецификации) операций класса или компонента, но он никогда не определяет физические реализации операций.

Кооперация определяет взаимодействие, например классов. Участвуя в кооперации, классы совместно производят некоторый кооперативный результат. Один и тот же класс может принимать участие в нескольких кооперациях. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, как показано на рисунке 33.

Компонент – это физическая часть компьютерной или иной системы. Компонент соответствует некоторому набору интерфейсов и обеспечивает физическую реализацию этого набора. Компоненты могут быть разных видов. Например, одним из видов компонент, используемых для моделирования программного обеспечения компьютерной системы, могут быть файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, как показано на рисунке 33. Внутри прямоугольника обычно пишется только имя компонента.

Пиктограммы – это логические кирпичики из которых составляются UML-диаграммы.

4.4.3. UML-диаграммы

Диаграммы прецедентов

Диаграмма прецедентов (use case diagram) – это графическое представление всех или части актеров, прецедентов и взаимодействий между ними. В каждой системе обычно есть главная диаграмма прецедентов, которая описывает внешнюю границу системы и основные внешние функции (внешнее поведение) системы. В качестве примера диаграммы прецедентов мы рассмотрим диаграмму, изображающую все прецеденты для одного актера, которым является, например, регистратор учебных курсов. Эта диаграмма показана на рисунке. 34.

Рис. 34. Пример диаграммы прецедентов «Регистратор учебных курсов»

Диаграммы классов

Диаграммы классов применяются для моделирования объектно-ориентированных систем. На простых диаграммах показываются классы и отношения между классами. На сложных диаграммах показываются классы, интерфейсы, кооперации и отношения между ними. Диаграммы классов дают статический вид системы. Можно также сказать, что диаграммы классов представляют собой взгляды разработчиков на статические состояния проектируемых систем. С помощью диаграмм классов составляется словарь системы. Диаграммы классов являются основой для создания диаграмм компонентов и развертывания. Следует особо подчеркнуть, что диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых кодов систем. На рисунке 35 приведен пример простой диаграммы классов, моделирующей объекты системы регистрации курсов и отношения между ними.

Рис. 35. Пример диаграммы классов «Система регистрации курсов и отношения между ними»

UML диаграммы классов включают в себя как частный случай диаграммы «сущность-связь», которые используются для логического проектирования реляционных, объектно-ориентированных и гибридных объектно-реляционных баз данных.

Диаграммы состояния

Диаграммы состояния описывают все возможные состояния класса и возможные переходы из одного состояния в другое, то есть моделируют все возможные изменения состояний объекта как реакцию на внешние воздействия. Диаграмма состояний является графом специального вида, который представляет собой некий автомат. Вершинами графа являются возможные состояния автомата, а дуги обозначают переходы из состояния в состояние. Диаграммы состояния могут быть вложены друг в друга для детализации представления.

Диаграммы деятельности

Диаграммы деятельности применяются для моделирования процесса выполнения операций. Применяемая на ней графическая нотация похожа на диаграмму состояний. Каждое состояние на диаграмме деятельности соответствует результату деятельности некоторой операции, а переход в следующее состояние выполняется только при ее завершении. Основным направлением использования диаграмм деятельности является визуализация алгоритмов.

Диаграммы взаимодействий

Диаграммы взаимодействий предназначены для графического отображения не только последовательности взаимодействия, но и всех структур, участвующих в этом взаимодействии. На диаграмме взаимодействия изображаются все участвующие во взаимодействии объекты, которые обозначаются прямоугольниками, содержащие имя объекта, его класс, значение атрибута. Далее указываются ассоциации между объектами в виде соединительных линий. При этом могут быть явно указаны имена ассоциаций и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи, потоки сообщений.

Для физического представления моделей используются следующие виды UML диаграмм: диаграммы компонентов и развертывания.

Диаграммы компонентов

В отличие от ранее рассмотренных описывают особенности физического представления систем, позволяющие определить архитектуру разрабатываемых систем, установить зависимости между программными компонентами, в роли которых может выступать исходный или исполняемый код. Основными графическими компонентами являются компоненты, интерфейсы и зависимости между ними. Диаграммы компонентов разрабатываются для следующих целей:

- визуализация общей структуры общего кода программной системы;

- спецификация использования варианта системы;

- обеспечение многократного использования отдельных фрагментов программного кода;

- представления концептуальной физической схем БД.

Диаграмма развертывания

Диаграмма развертывания предназначена для представления общей конфигурации и топологии распределенной программной системы. Диаграмма развертывания использует визуализацию компонентов программ, существующих лишь на этапе ее выполнения. При этом представляются только компоненты программ, являющихся исполняемыми файлами или динамическими библиотеками. То есть, компоненты, которые не используются на этапе исполнения, на диаграммах развертывания не показываются. Диаграмма развертывания содержит графическое изображение процессора, устройств, процесса и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для всей системы. Разработка данной диаграммы, как правило, является последним этапом спецификации модели программной системы. При разработке диаграммы развертывания преследуют следующие цели:

- определить распределение программных компонентов системы по ее физическим узлам;

- показать физические связи между всеми узлами реализации систем на этапе ее исполнения;

- выявить узкие места системы и изменить ее топологии для достижения требуемой производительности.

Разработка диаграмм развертывания начинается с идентификации всех аппаратных, механических и других устройств, которые необходимы для выполнения системой всех своих функций. Далее, при построении диаграмм размещения, все исполняемые компоненты размещаются по узлам системы. Если отдельные исполняемые компоненты оказались неразмещенными, такая ситуация должна быть исключена введением в модель дополнительных узлов.

Таким образом, язык UML позволяет:

- формализовать функциональные требования к системе с помощью диаграммы использования;

- выделить классы данных, построив концептуальную модель с помощью диаграмм классов;

- описать процесс взаимодействия объектов при выполнении функций;

- описать поведение объектов в виде диаграмм состояний;

- показать программные компоненты и их взаимодействие через интерфейс;

- представить физическую архитектуру систем.

СПИСОК СОКРАЩЕНИЙ

АИС – автоматизированная информационная система

АСУ – автоматизированная система управления

ВЦ – вычислительных центрах

ЖЦ – жизненный цикл (информационной системы)

ИС – информационная система

КИС – корпоративная информационная система

НСО – нормативно-справочное обеспечение

ПО – программное обеспечение

СПО – системного программного обеспечения

СУБД– система управления базой данных

ANSI – Национальный Институт Стандартизации США (American National Standards Institute)

BL – бизнес-логика, прикладная логика информационной системы (business logic)

CASE– автоматизированное проектирование и создание программ (computer-aided software engineering)

DL – логика управления данными (data logic)

DS – операции с базой данных (data services)

DSS – система поддержки принятия решений (Decision Support System)

ER – методология «сущность-связь» (Entity-Relationship)

ERA – расширенный реляционный анализ (Extended Relational Analysis)

ERD – диаграмма сущность-связь (Entity Relationship Diagram)

FA – полная атрибутивная модель (Fully Attributed model, FA)

FK – внешний ключ (foreign key)

FS – файловые операции (file services)

ISO – Международная организация по стандартизации (International Organization for Standardization)

KB – модель данных, основанная на ключах (Key Based model)

OLTP – оперативная обработка транзакций (on-line transaction processing)

OO – объектно-ориентированный подход (Object Oriented - OO)

ORM – объектно-ролевое моделирование (Object Role Modeling - ORM)

PK – первичный ключ (Primary Key)

PL – логика представления (Presentation Logic)

PS – средства представления (Presentation Services)

SADT– метод структурного анализа и проектирования (structured analysis and design technique)

SQL – язык структурированных запросов ( международный стандартный язык для определения и доступа к реляционным базам данных – Structured Query Language)

UML – язык объектно-ориентированного анализа проектирования (Unique Modeling Language)